Figure 1: Levels of verification and what each of them catches — inner consistency can be automated, correctness cannot.

What remains is the part no tool covers. Neither the static analysis nor the mutation testing would have noticed that the import breaks off at one hundred tasks, for both check the agreement of code and test, not the agreement of result and reality. That falls to the human who knows their own body of data. The division of labour that follows from this is unspectacular but sound: the assistant produces, the tools verify inner consistency, and the human verifies whether the whole thing is the right thing at all.

Bug fixing and fitness for daily use

The bug fixing produced the most instructive find of the whole undertaking. The import ran flawlessly at first — too flawlessly. It fetched one hundred tasks and reported success. That the ClickUp interface delivers its results page by page and silently truncates after a hundred entries only came to light when the figures did not match the actual body of data. The fix walked the pages in a loop and concatenated them into a single raw document, with a hard upper bound so that a misbehaving interface can never lead into an endless loop. This is the sort of error no tool finds for you: there was no exception, no failing test, no warning — only a result that looked plausible and was wrong. Here the limit of the acceleration shows itself quite precisely. The tool wrote the import effortlessly; that it imported too little was noticed by the human who knows their own body of data.

Less dramatic, but telling, was the second group of findings. A static analysis found seventeen complaints in the code of the publication management, all of the boring kind: missing serialisation identifiers on the views, mutable collections passed straight out that are better copied defensively. They were resolved with fifty-six added lines. It is precisely that layer of craftsmanlike care which an assistant reliably overlooks as long as no one points it out — and which an analysis tool just as reliably finds. That the two together are better than either alone is the actual lesson.

This phase also confirmed what the view briefs had predicted. The editorial board and the history view remained custom builds; at three hundred and fifty-four lines the board is the second-largest of the seven publication views, complete with hand-wired drag-and-drop between the columns. This was no rude awakening, because it had been announced — and therein lies the whole value of a design plan that names its gaps.

What came afterwards is the actual work on an application one wants to use daily, and it fills releases thirty-two to forty: filters across several criteria, tag combinations as either AND or OR, adjustable column widths, return paths that lead back to where one came from, entries editable in place. This phase cannot be shortened, for it consists entirely of small observations one makes only once one really uses one’s own tool. The assistant implements them quickly; it is the user who must notice them.

On balance the calculation held, but not in the way naive expectation would suggest. The path from the empty directory to a usable application was, for an individual working alongside their ongoing commitments, remarkably short. The acceleration, however, lies almost entirely in the making — in the writing of classes, views, tests and translations. It does not lie in the discovering. The truncated import, the wrong return path, the awkward handling: all of that had to be noticed by someone who knows how the thing ought to feel.

An honest balance sheet

An article that tells of a calculation tipping over owes the reader both columns of that calculation. My first draft of this chapter had a flaw I noticed only on re-reading: it listed the costs of the self-built solution meticulously and set against them a rented service whose costs remained unquantified. That is not a balance sheet, but a one-sided statement. So: both columns.

The item that cannot be argued away is maintenance. Every library ages, security vulnerabilities are reported, a new Java release appears — and no one but me will attend to it. This work does not end. It is, however, smaller than the word suggests, and precision helps more here than drama: this is an application with a single user, without an availability guarantee, without tenant separation and with few dependencies. The effort accordingly remains manageable.

More decisive than the size of this item is its nature, and here lies the actual gain. My maintenance burden obeys me. I decide when to raise a dependency; if I touch nothing for a year, the application continues to run as before. The changes of a rented service, by contrast, befall me. I can neither schedule nor decline them: prices rise, features disappear or are rebuilt, an interface is rearranged, a provider is acquired. Both are costs, yet only one kind is under my control. This distinction between costs one commands and costs that befall one is the substantive core of what I mean by sovereignty.

Which brings us to the second column, missing from the draft. ClickUp cost more than a monthly fee. It cost the daily detours from the first chapter — the makeshifts via tags, the overloaded status field, the impossibility of asking a single question cleanly. It cost the operation of an abundance of features of which I used a narrow slice. And it cost something that becomes visible only in earnest: the ability to leave. Whoever owns neither their data nor the source code cannot switch when faced with an unwelcome change, but only acquiesce. These items appear on no invoice, and that is precisely why one overlooks them for years.

The third item is dependency, and here I must examine my own principles. I like to keep close to the JDK; neither Spring nor Jakarta EE appears in this application. This is no idiosyncrasy but follows from the scope: an application server and a dependency-injection framework solve problems I do not have here — tenants, distributed transactions, interchangeable implementations within large teams. Vaadin Flow runs on an embedded Jetty, the wiring is done by ordinary Java code, and what remains can be read and surveyed in full. Vaadin, however, is anything but a small dependency — an extensive framework with a runtime world and a build tooling of its own. Whoever adopts it exchanges the fault line between Java and JavaScript for a tie to one vendor. I consider the exchange advantageous, because it removes precisely the friction that otherwise cost me most, and because the result sits with me as open source and remains compilable even if I update nothing further. An exchange it nonetheless remains. Added to this are the object store and a tool for reading JSON; the application is far from “only the JDK”. The aim was always restraint, not asceticism.

The fourth item concerns the reverse side of data sovereignty. My data now sit with me — and so does the responsibility for them. About backups, failing drives and a move to new hardware I never had to think with ClickUp. Now I do. At least this item is solvable and set up once, and it has a reverse side that weighs more heavily for me: a backup I make myself I can also restore myself — and I know what format it is in.

Something must also be said about the assistant that the account so far only touches upon. It has accelerated the making extraordinarily, but it possesses no judgement as to whether what has been made is correct. The truncated import from the previous station is the best example: clean code, green tests, wrong result. The tests carry this weakness within them too, for they check what the assistant understood — a misunderstanding propagates from the code into the test and is confirmed there. Whoever works this way needs means of verification from outside: static analysis, an assessment of test quality through deliberate corruption of the code, and above all one’s own eye. This insight does not argue against the path, but it determines how one walks it.

Two points I leave without consolation, because none is due to them. The first is dependency on a single person: were I to drop out, there would be no one to maintain this application further. With a rented service that would be otherwise, and no argument helps against it. The second is the timing of this article: the application is still young. Whether it proves itself in daily use over months, whether decisions that look sensible today will come back to haunt me in half a year — that I simply do not know. Anyone claiming certainty here does not have it.

A good deal has moreover remained open. The PDF generation, one of the original motives, is not implemented and will require a further deliberate exception to the dependency principle. The commercial world was left out — rightly so, but it is missing. The import serves its purpose, yet the final switchover with a cut-off date and a reconciliation is still to come.

There remains the question of what the calculation now looks like. Its two sides run in opposite directions: the building effort was one-off and lies behind me, the rent would be recurring and would, by experience, grow. The benefit persists for as long as I write, and it consists not merely in fees saved but in something that was previously impossible — an application that mirrors my workflow instead of pressing it into a foreign model, data in a format I know, and source code that lives on without the assistant that helped write it. The calculation has therefore tipped over, but it has not become trivial. It does not read “building your own is now free”, but rather: the building effort has fallen so far that ongoing maintenance becomes the decisive item. And that maintenance is, unlike the changes of a foreign service, a burden one holds in one’s own hands.

Outlook

Three steps are foreseeable, and they stand in a natural order.

The next is the final switchover. So far the new application runs alongside ClickUp, fed by an import that can be repeated at will. At some point there will need to be a cut-off date, a last reconciliation and the decision to stop feeding the old service. That moment is unspectacular and at the same time the real test: only when I use the tool without a fallback will it become apparent whether it is fit for purpose.

The second step is the PDF generation — that motive from the first chapter which has so far remained unfulfilled. Typesetting collected editions from the body of work was never conceivable with a task manager, and now it is merely a question of doing the work. It will require a further deliberate exception to my dependency principle, for the JDK brings nothing along for typesetting documents. That I make this exception and do not conceal it is preferable, to my mind, to pretending that everything can be built from on-board resources.

The third step is the commercial world I deliberately set aside in the first part: clients, remuneration models, invoices, a forecast of expected income. The lean model was designed from the outset as a genuine subset, not as a stopgap, and the transition therefore proceeds by addition rather than by rewriting. Whether this assurance holds remains to be seen — it is the kind of promise one makes to oneself and which reality occasionally declines to honour.

And beyond that? The appeal of one’s own application lies in the fact that every small observation in daily work can lead directly to a change, rather than to an entry on a wish list administered by someone else. That is precisely the difference I was looking for at the beginning without being able to name it: I was not seeking a better ClickUp, but a tool that obeys me instead of shaping me. Whether the calculation works out in the long run I shall know in a year. That it could be drawn up at all is new — and that is the actual news of this article.

Related on this site

• From ClickUp to Vaadin — Part 1: The Thesis and the Model — the first part: the direct look into the running ClickUp workspace, the disentanglement of one status field into three orthogonal dimensions, and the hardened append-only history.
• Vaadin Flow — How to Start — the entry-level walkthrough for the framework used throughout this account.
• The Security Innovations in Vaadin 25.2 — the platform-level defaults this application inherits from Vaadin’s own runtime.

https://svenruppert.com/posts/from-clickup-to-vaadin-part-1-the-thesis-and-the-model/Fri, 21 Aug 2026 09:00:00 +0200sven.ruppert@gmail.com (Sven Ruppert)Sven Rupperthttps://svenruppert.com/posts/from-clickup-to-vaadin-part-1-the-thesis-and-the-model/Managing a decade of writing in ClickUp taught me exactly where a foreign task tracker starts working against you: sixteen status values in one field, four content levels concealed in a naming convention, and a monthly bill for an abundance I never used. This first part is the analysis and the model — the direct look into the running workspace, the disentanglement of one status field into three orthogonal dimensions (acquisition, editorial work, production), the append-only history hardened by a sequence number rather than a timestamp, and the seven-view draft with its honest seams. Data sovereignty is no longer a privilege of large organisations with development departments — AI-assisted development makes the tailored, self-built option affordable for the individual, and the thesis of this two-part account is that the calculation has tipped over.<![CDATA[

The Motivation

For many years I have managed my writing in ClickUp: the topics I am working on, the individual articles, their translations, the places where they appear, and the commercial handling that comes with them. Over time a considerable body of data has accumulated there, and in many respects the tool does what it should. It was not the dissatisfaction of a single grievance that made me reconsider, but the slow accumulation of several small frictions, until the question became unavoidable of whether things had to continue in this way.

The first friction is fundamental in nature. My data resides in a cloud on the far side of the Atlantic, on servers whose legal and political framework I do not determine. For notes this may be a matter of indifference; for the collected work of many years, together with the names of clients and the terms behind them, it is not. The wish to regain sovereignty over this body of data has, over time, grown from a diffuse unease into a clear requirement.

The second friction is, in a sense, the opposite of a shortcoming. ClickUp grows more powerful year by year and takes on ever more of what teams might need — only I need the least of it. I pay for and operate a growing abundance of which I use a narrow slice, and with every new feature the tool becomes a little heavier than it would need to be for my purpose. Bound up directly with this is the third friction, the plainest of all: it costs money, month after month, for a benefit that bears no good relation to it.

The fourth friction is the truly telling one, for it is not one of price but of fit. My workflow calls for distinctions that ClickUp’s model does not provide for, and so I make do, as one does: with tags, with additional fields, with a single status field onto which I load more meanings than one field can bear. It works, in the way a tool works when it is repurposed — not wrongly, but always slightly against the grain. It was precisely here that the suspicion took root that my workflow possessed a structure which the foreign tool did not reveal to me but concealed.

And finally, I want to make something of this data that goes beyond merely managing it: to compile it into PDFs, to bundle it into collected editions, to publish from the body of work itself. That is not a task a task manager is meant for, and the longer I thought about it, the clearer it became that I was not looking for a better ClickUp, but for something else.

So at the outset there stood not a decision, but a sum of observations — and the question of whether one continues to endure the foreign software because building one’s own seemed too expensive, or whether something about that calculation has meanwhile changed.

The Thesis

Until recently I would have answered this question quickly, and to the detriment of building my own. A bespoke application that mirrored my workflow exactly and kept my data on my own ground was simply uneconomical for an individual. The design of the model, the interface, the persistence, the many small paths in between — all of this costs time, and time is the most expensive item of all for an individual. So one endures the foreign software together with its proliferation of features, because the alternative does not pay off. That calculation held true for years.

What has changed is not my aspiration, but the price of fulfilling it. An AI-assisted workflow shifts the effort that hitherto argued against building one’s own so far that the calculation tips over. Not because a machine relieves me of the thinking — the substantive decisions remain mine — but because the path from the idea to a working draft is shortened so greatly that the tailored, self-built option suddenly becomes worthwhile. And precisely therein lies the actual thesis of this article: data sovereignty is no longer a privilege of large organisations with their own development departments. AI-assisted development makes one’s own, precisely fitting application affordable for the individual as well.

This thesis has three limbs that ought to be kept apart. Data sovereignty is the why — the reason I take this path at all. AI-assisted development is what is economically new, and it is what makes the path passable in the first place; it is the answer to the question of how this should be possible for an individual at all. And the with-what is a tool with which such an application can be built consistently in a single language, from the data model through to the interface, without the otherwise customary break between the two worlds — more on that later, at the point where it shows itself of its own accord.

At this point an objection presses forward that I would rather voice myself before a reader formulates it. I speak of sovereignty and independence — and at the same time I let an AI assistant from a US provider design my model and build my interface. Is that not a contradiction that undermines the whole account? It is not, as soon as one looks closely at what is meant to be sovereign here. Sovereignty means authority over the place, the format and the ownership of my data, as well as over the source code that ultimately runs on my own infrastructure and lives on there at will — without the assistant that helped to write it. The AI is a tool of production, not a component of operation. It stands at the beginning, as the carpenter stands by the house that is afterwards inhabited without them. Whoever does not draw this distinction between production and operation sees a contradiction; whoever draws it sees the division of labour that carries the whole path in the first place.

Understood in this way, the AI is not the adversary of sovereignty but its enabler — and what remains at the end belongs to me: the data, the model, the source code. What this path looked like in detail is the subject of the rest of this article.

The Process as Evidence

Before I describe the individual stations of this path, I must speak about the manner in which it was travelled — for that manner is not incidental, but is itself the argument. An article that claims AI-assisted development makes the tailored, self-built option affordable could fill that claim with figures and promises. It is more convincing to demonstrate the process and let readers judge for themselves. That is precisely the intention: the path is the evidence.

At the outset there stood not my description of ClickUp, but the direct look into it. Through a tool connection the assistant had access to my running workspace and read it itself — the lists, the custom fields, the status values, the actual tasks. That is a fine but decisive difference. Had I described the structure from memory, a smoothed, already-interpreted version would have emerged; as it was, however, the analysis began from reality, together with its inconsistencies and with what I myself had ceased to notice consciously over the years.

What followed was not a dictation, but a conversation. I made the substantive decisions — what a topic is, how a status is to be understood, what may fall away — while the assistant proposed, arranged, asked questions and at one point even hardened the model against my first draft. The roles remained clearly distributed throughout: I am the architect who knows what the application is to accomplish; the tool is the fast, tireless fellow-thinker that supplies drafts, formulates objections and takes on the implementation. From this division of labour arises the acceleration that makes the calculation mentioned at the outset tip over.

Honesty requires acknowledging that this process does not proceed without friction. The assistant errs, at times gets ahead of itself, reads in something I did not intend, and has to be reined back in. Yet precisely therein lies the confirmation of the division of labour: it takes the human judgement that holds the direction and notices the misstep. The tool accelerates the making; it does not replace the one who knows where things are meant to go. What this path looked like in detail is the subject of the stations that follow — and the first leads to the origin of it all: into the running workspace itself.

Taking stock of the running system

At the outset, as announced, there stood not my account but direct access. Through the tool connection, the assistant read my running workspace at first hand — not an exported copy, not a memory-borne retelling, but the system in which the work actually resided. This circumstance matters more than it first appears. Anyone who describes their own practice from memory already supplies an interpretation; the inconsistencies are smoothed away, the habits straightened, what grew over time forced into an order it never possessed. The look into the running system, by contrast, shows the holdings as they are, together with everything that had crept in unnoticed over the years.

What showed itself was, at first, of disarming plainness: a single list. No web of folders, no hierarchy of sub-lists, but a flat sequence of tasks whose names obeyed a strict pattern — a prefix of hyphen-separated parts that carried the actual structure. Only this prefix betrayed that the seemingly equal-ranking entries in truth denoted different things and lay at different levels. The structure was present, but it did not reside in the system; it resided in a naming convention I had imposed upon myself and half forgotten over time.

More revealing than the list was the individual task, once one expanded it in full. A name, a description, a status value, a series of labels — and, alongside these, custom fields I had once created to wrest from the tool what it did not offer of its own accord. It is precisely in this abundance that the value of direct examination lies: it brings home how much domain meaning is dammed up in a single record that the foreign tool carries as an unadorned line. What the model was later to prise apart into levels and dimensions still lay here one atop another, folded together into a single entry.

Part of the honesty of this approach is an inconsistency that revealed itself along the way. The obvious route to gathering the custom fields would have been the call provided for exactly that purpose — yet for this workspace it returned an unusable result, in which even the fields’ mandatory flag came back empty. What proved reliable instead was the detour by way of a single, named task, retrieved in full detail, from which the field structure could be read off beyond doubt. This is a small observation, but a telling one: the direct look into the living system uncovers not only one’s own structure but also the idiosyncrasies of the tool with which one reads it out. Had I relied on description, both would have remained hidden.

At the end of this stocktaking there stood not a design but a sharpened view of what was there: a flat list that concealed a multi-level structure, and tasks that carried far more meaning than their plain appearance would suggest. One field among them was to prove especially telling — that single status field into which too much had migrated over the years. To it the following stage is devoted.

Analysis: the conflated status field

The first real step was not a design but an inventory — and it began where the data actually reside. The assistant read out my running workspace itself: a single list whose tasks bear names like “Blog – Navigation – Koppelnavigation” — German for coupled navigation. What looks at first glance like a plain task list conceals, on closer inspection, a structure that ClickUp nowhere states.

For ClickUp knows only one level: the task. Everything sits within it at once. In truth, however, my work is organised into four levels that surface only in the name prefix. The topic — the “issue” — is the subject-matter bracket; beneath it stands the part as a language-neutral instalment; to it belong the language versions, one per language; and only the publication binds a version to a concrete place. These four levels are compressed into the flat task and must be reconstructed from it, not merely carried over.

Figure 1: A single ClickUp task versus the four-level target structure.

The more telling discovery, though, concerned the status. ClickUp kept a single status field, and into this field I had, over the years, pressed sixteen values: frombacklog,planned,in progress andreview, throughoffered,accepted andin pipeline, toscheduled,draft published,published,update required,ready for billing,paid,on hold,skipped andclosed. Taken on its own, each value makes sense. Side by side in one field, however, they answer quite different questions — and that is precisely the problem.

For within this single field there are three mutually independent kinds of progress. The first is the editorial work state: how far has the text come? The second is the production of the publication: is it planned, prepared, published? The third is acquisition: has the work been requested, offered, agreed? These three questions are orthogonal — they stand perpendicular to one another and can be answered independently. An agreement may long since be in place while the text is still being written and the publication not yet scheduled. Force all three into a single field, and one of the kinds of progress must always displace the other two.

Figure 2: One conflated status field, decomposed into three orthogonal dimensions.

Two values expose the overloading with particular clarity.paid is not a state of the content at all, but a property of the invoice; it had merely strayed into the status field for want of a home of its own. Andon hold is no phase whatsoever, but a resting that cuts across all three — enter it, and it overwrites the actual progress and effectively erases it. Both are unmistakable signs that a single field was bearing loads never intended for it.

The consequences are felt in daily use. Whenever I wanted to know which parts were in copy-editing, production and sales states mixed into the answer; a clean view of a single question was not to be had. The foreign tool did not show me my workflow, it concealed it behind a single, overladen column. With that, the actual task lay plainly exposed: to decompose the one field into three clear, independent dimensions — and that very disentangling is the subject of the stations that follow.

Take over, decompose, refine, strike out

The analysis had named the task, not solved it. Sixteen values lay in a single field, three questions were concealed within it, and between that insight and a sound model stood the actual work: to interrogate each individual value as to where it belongs. This work falls into four operations, and the heading names them in the order in which they pressed themselves upon me — take over, decompose, refine, strike out.

The first operation is the easiest, because it overturns nothing. A portion of the values did describe what they purported to describe: the progress of the editorial text.backlog,in planning,in progress andreview are genuine working states, and they migrate unchanged into the editorial dimension, which the model carries as the enumerationEditorialState, running fromBACKLOG throughIN_PLANNING,IN_PROGRESS andREVIEW to the terminal statesDONE,SKIPPED andCANCELLED. For these values the migration meant no interpretation, merely plain adoption.

The second operation is the true heart of the whole undertaking. For several values that stood companionably beside the working states in the ClickUp field were in truth answering an altogether different question.offered,accepted andin pipeline say nothing about the text but about acquisition — about whether a piece of work has been requested, offered or agreed. They belong on an axis of their own, which the model maintains asAcquisitionStatus with the valuesREQUESTED,OFFERED,ACCEPTED andREVIEW up to its own terminal states. The same holds forscheduled andupdate required: they concern the production of the publication, not the text, and find their place on the third axis,ProductionStatus, withPLANNED,PREPARED,PUBLISHED andUPDATE_NEEDED. What lay compressed into a single field is here distributed across three mutually perpendicular dimensions — this is the decomposition from which the entire argument proceeds.

The third operation concerns the cases in which a single value does not simply relocate but requires clarification. This shows most clearly withpublished. That one value bears two meanings at once: it reports that the text is finished and that the publication has appeared — an editorial and a production statement in a single word. In the decomposition it must divide, and the editorial side falls, consistently, uponDONE. Part of the refinement, too, is the unification of the spellings that had accumulated over the years: whether I had notedto do,todo orplanning, whethercancelled orcanceled — the mapping reduces these variants to a single canonical target state each, and only thereby renders the collection amenable to evaluation. And because no design foresees reality in full, every unanticipated value issues not into nothing but, cautiously, into the initial stateBACKLOG, from which it remains visible and can be put right by hand.

How closely this refinement sits to the code is shown by the case distinction with which the import later maps every source value onto the editorial axis:

javaCopy

/** Distributes the conflated ClickUp status onto the editorial state. */publicstaticEditorialStatemapStatus(Stringclickup){Strings=clickup==null?"":clickup.toLowerCase().strip();returnswitch(s){case"in progress","in-progress","progress"->EditorialState.IN_PROGRESS;case"review","in review"->EditorialState.REVIEW;case"planning","in planning","planned","to do","todo"->EditorialState.IN_PLANNING;case"done","complete","completed","closed","published"->EditorialState.DONE;case"skipped"->EditorialState.SKIPPED;case"cancelled","canceled"->EditorialState.CANCELLED;default->EditorialState.BACKLOG;};}

The spellings drawn together in each branch are the refinement; the final branch is the cautious fall back into the backlog. At the same time the excerpt names its own limit: it knows the editorial axis alone. Why the two other dimensions must arrive empty from the source is the subject of the second part.

The fourth operation, finally, removes what has no business on any of the three axes.paid is not a state of a piece of content but a property of the invoice; it had strayed into the status field only for want of a home of its own, and it leaves the content dimensions without replacement.ready for billing shares this fate, for readiness to invoice, likewise, is a matter of the invoice, not of the text. Andon hold, the second tell-tale value from the analysis, is no phase at all but a resting that lies athwart all three; were it entered as a status value, it would overwrite the actual progress and, in effect, erase it. It is therefore struck from the status axis rather than allowed to falsify it.

At the end of these four operations there stands a mapping table: on the left the accumulated values of the source, on the right their place in one of the three dimensions — or the reasoned finding that they have no place there. This table is more than an overview. It is the bridge between the analysis and the code, and it returns in two guises: as the hardened model in the following stage, and as an executable case distinction in the import of the second part — though the import executes only its editorial column; why the other two dimensions start empty is shown in the second part. The observation has thereby become a prescription that can be tested.

Figure 1: How the sixteen ClickUp status values were resolved by the four operations — taken over onto the editorial dimension, decomposed onto acquisition and production, the split refinement of “published”, and the strikings-out from the status axis.

Model hardening: the tool thinks along

The analysis ended with a clear task: to decompose the one overloaded field into three independent dimensions. But a decomposition alone is not enough — what matters is how one anchors it in the code so that it holds. It was precisely here that something happened which I regard as the true essence of AI-assisted work: from a passing observation there grew a structural improvement that I had not even foreseen in my first draft.

The starting point was a plain concern that I voiced in conversation. If each of the three dimensions keeps its history as a list of status changes, then that list lies open — and an open list can be reordered by accident, extended in the wrong place, or relieved of entries. For an audit trail meant to prove in what order a state has developed, that is a dangerous weakness. What began as a small remark led to a hardening that rests on two pillars.

The first pillar makes the order independent of the list position. Every status change carries a strictly ascending sequence number, and it is not the timestamp that decides the order, but this number. The timestamp remains descriptive — for clocks jump, and two events might bear the same instant.

javaCopy

publicrecordStatusChange<SextendsEnum<S>>(longsequence,Sfrom,Sto,Stringactor,Instanttimestamp){publicStatusChange{if(sequence<0){thrownewIllegalArgumentException("sequence must be >= 0, was "+sequence);}Objects.requireNonNull(from,"from");Objects.requireNonNull(to,"to");Objects.requireNonNull(timestamp,"timestamp");}}

That this event is a record seems incidental, yet it carries the entire guarantee: a record is immutable, so that a change once written down can no longer be altered afterwards — neither the sequence number nor the source or target state. The tamper-resistance of the history therefore rests not on conventions but on a property of the language. The application compiles against Java 26 and may of course make use of such means.

The second pillar prevents reordering from the outset by not exposing the list at all. In its place stands a generic history that keeps the events private and offers only two capabilities to the outside: the readingevents(), which returns an immutable view, and the appendingrecord. There is no inserting, removing or reordering.

javaCopy

publicfinalclassStatusHistory<SextendsEnum<S>>{privatefinalSinitial;privatefinalList<StatusChange<S>>events=newArrayList<>();publicStatusHistory(Sinitial){this.initial=Objects.requireNonNull(initial,"initial");}publicScurrent(){returnevents.isEmpty()?initial:events.get(events.size()-1).to();}publicvoidrecord(Sto,Stringactor){record(to,actor,Instant.now());}publicvoidrecord(Sto,Stringactor,Instanttimestamp){Objects.requireNonNull(to,"to");Objects.requireNonNull(timestamp,"timestamp");Sfrom=current();events.add(newStatusChange<>(events.size(),from,to,actor,timestamp));}publicList<StatusChange<S>>events(){returnList.copyOf(events);}}

The whole point sits in this small type. Becauserecord derives the source valuefrom itself from the current state and assigns the next sequence number, neither an inconsistent transition can be injected nor the order falsified. And becausecurrent() always reads the current state as the target of the last event, rather than storing it separately, it can never diverge from the history. What was previously a matter of discipline — please do not reorder the list — is now a property of the type. These guarantees are not a mere promise of the prose; the model is accompanied by tests such asStatusHistoryTest andStatusChangeTest that pin down exactly these.

The real gain shows itself when the same history serves all three dimensions. The dimensions themselves are plain enumerations — production, for instance, knows four values:

javaCopy

publicenumProductionStatus{PLANNED,PREPARED,PUBLISHED,UPDATE_NEEDED}

The editorial work state and acquisition each carry seven values together with anisTerminal() that marks their terminal statesDONE,SKIPPED andCANCELLED. On thePart hangs the editorial state alone; thePublication, by contrast, carries two orthogonal lifecycles at once — production and acquisition — each with its own hardened history. It is here that the disentangling from the analysis becomes executable code:

javaCopy

publicPublication(UUIDid,LanguageVersionversion,PublicationPlaceplace){this.id=Objects.requireNonNull(id,"id");this.version=Objects.requireNonNull(version,"version");this.place=checkLanguageRule(version,Objects.requireNonNull(place,"place"));this.production=newStatusHistory<>(ProductionStatus.PLANNED);this.acquisition=newStatusHistory<>(AcquisitionStatus.REQUESTED);}publicvoidchangeProductionStatus(ProductionStatusto,Stringactor){production.record(to,actor);}publicvoidchangeAcquisitionStatus(AcquisitionStatusto,Stringactor){acquisition.record(to,actor);}

Two independent histories on a single object — that is the decomposition which was impossible in the conflated ClickUp field, yet here stands as a mere matter of course. In passing, the constructor watches over the language rule: a publication may point only to a place whose supported languages include the language of the version; otherwise it does not come into being at all.

In retrospect this step is, for me, the most convincing evidence of the thesis set out at the beginning. Not because a machine devised the model — the substantive direction remained mine — but because an attentive fellow-thinker took up a passing concern and translated it into a construction that hardens the model at a real weak point. That is what “the tool thinks along” means in concrete terms. How a coherent concept grows out of this hardened model, and the interface out of that, is what the following stations show.

Where the data reside: the object graph

A word on persistence, which seems inconspicuous beside model and interface, yet is essential to the concern of the whole. The data do not reside in a relational database, but as an object graph that EclipseStore writes into files on my own disk. This dispenses with the entire intermediate layer that otherwise mediates between objects and tables: no schema, no mapping, no migration scripts, no database server wanting to be maintained and backed up. For a body of data of this order — a single user, a few hundred topics — that is simply the leaner solution. Above all, though, it makes data sovereignty tangible: what belongs to me sits as a directory on my disk, copyable, backupable, portable. An object store admittedly ties me more closely to Java than an open tabular format would; for an application that consists entirely of Java in any case, I consider that price appropriate.

From the model to the concept

A hardened data model is not yet an application. Between the classes and the interface lie two steps that are easily skipped and then dearly paid for: condensing the model into a coherent concept, and deriving the screens from the working processes. Both steps came about in the same manner as everything before them — in conversation, with a clear division of roles.

The domain concept summarises what the model expresses only in types: the four content levels and the fact that they must be reconstructed from the flat ClickUp task; the three status dimensions and their carriers; the history as a chain that proves; the language rule, according to which a publication may point only to a place whose languages include that of the version. Above all, however, it records what doesnot belong to it. The entire commercial world — legal entities, remuneration models, invoices, forecasts — was deliberately left out. This omission was not economising in the wrong place, but method: a model that seeks to depict everything at once is never finished, and for the first working state it is the core that counts.

The process catalogue: views follow from processes

The second step was the more important one, and it is the one I shall never omit again. It would have been obvious to derive the screens directly from the data model — a form for every class, a table for every list. Everyone knows the result of such derivations: interfaces that display everything and support nothing. Instead, a catalogue of working processes came first: twenty procedures with fixed identifiers, from “create topic” through “advance the editorial state” and “manage acquisition” to the three steps of the import. Each entry names its purpose, the level affected and the state transition it triggers.

Only from these processes were the views then derived, and in such a way that every screen explicitly records which processes it serves. This tying-back sounds like bureaucracy, yet it proves to be the sharpest tool against superfluous interfaces: a screen that cannot invoke any process is dispensable; a process without a screen is a gap. Seven views remained, along with the question of how they stand in relation to one another.

The draft: seven views and their limits

At this point the tool came forward for the first time with a limitation rather than a possibility — and that is worth reporting. Vaadin brings with it a rich stock of building blocks, and for most screens the assignment was straightforward: tables, form layouts, selection fields, tabs, date pickers. For two views, however, there is no ready-made block. The editorial board with its columns per work state is not a standard component, and neither is a timeline for the history view. Both had to be assembled from layouts, drag-and-drop and custom cards. It would have been tempting to keep quiet about this; but a design plan that does not identify such places merely shifts the effort into the implementation, where it makes itself felt more unpleasantly.

From the view briefs there finally emerged an interactive draft. I handed over the four documents — type sketches, concept, process catalogue and view briefs — to a design tool with the plain request to make from them a first draft of an elegant working environment intended for daily use. What came back surprised me on one point. The draft had not merely drawn the screens, but had understood the logic behind them: the history view carried the note that the ordering rests on the sequence number and not on the timestamp, and the production dimension managed without the terminal states of the others, offering instead a specially labelled return step.

Figure 1: The publication view — acquisition and production as two equal columns.

This one screen is the culmination of the entire path. On the left acquisition, on the right production, equal in size, equal in weight, each with its own current state and its own history. What was impossible in the ClickUp field stands here as a matter of course: an agreement has been given while production is still under way — two truths side by side, neither displacing the other. One does not have to explain the disentangling; one sees it.

Figure 2: The topic workspace — a topic with its parts, tags and the recorded ClickUp origin.

Figure 3: The history view — the append-only chain, ordered by sequence number, with actor and timestamp.

A word of honesty about the limit of this step. The draft is a free front-end mock-up, not Vaadin code; the design tool does not know Vaadin’s stock of components and cannot query it either. Between draft and implementation there therefore runs a seam that no one should talk away — the view briefs, with their assignment to concrete building blocks, are precisely the thread with which it is later sewn up. How this seam was actually closed, and what came to light in the process, is the subject of the second part.

Does this hold up against reality?

At the end of this first part there stands a model, and models have the disagreeable property of always looking better under contemplation than in use. Before the first line of the application is written, the question that gives this stage its name is therefore in order. Three objections strike me as the most serious, and not one of them can be disposed of by further reflection.

The first concerns the foundation. The entire model is derived from a single workspace, that of a single author with his accumulated habits. What presented itself there as three orthogonal dimensions could equally well be the idiosyncrasy of an individual case. I do not claim to have found a general order for publishing work; I claim to have found a sound one for these particular holdings. The difference is considerable, and anyone treading the same path should begin with their own stocktaking and not with mine.

The second objection is directed against the disentanglement itself. That acquisition, editorial work and production proceed independently of one another is an assertion about reality, not a deduction from it. It rests on the observation that values which never excluded one another lay side by side in the source. Yet whether the three axes really prove independent in daily use — or whether a tacit coupling establishes itself between them after all, which then once again takes refuge in comment fields and labels — is decided by no act of modelling, but by use alone.

The third objection is the most uncomfortable, because it is already settled. The two newly won dimensions arrive from the migration empty. What was never gathered cannot be filled in retrospectively, and so the holdings taken over begin in initial states that say nothing about their past. The gain from the disentanglement lies entirely in the future. Such a promise may be redeemed or may come to nothing, and how it turned out belongs in the reckoning, not in the design.

It remains to record what follows from this examination. A model that has to hold its own only against itself always wins. The sole test that counts consists in sending the real holdings through it, working the views, and observing at which point the order tears. That is precisely the subject of the second part — not as proof of a successful design, but as its first serious loading.

Related on this site

• From ClickUp to Vaadin — Part 2: The Build and the Balance — the second part of this series: seventy-two commits, browserless view testing, mutation testing as a check on tests written by the assistant, and an honest reckoning of a calculation that has tipped over.
• When Security Boundaries Become Obstacles — the same principle at a different scale: an optimising system given a measurable objective will find routes its builders did not foresee. Applies to importers as much as to evaluation models.

]]>JavaVaadin