Browserless Testing on Sven Rupperthttps://svenruppert.com/tags/browserless-testing/Sven Ruppert — Java Veteran, Speaker, Trainer & Bushcrafter. Articles, talks, workshops and videos on Core Java, Cybersecurity, Vaadin and Developer Relations.Hugoensven.ruppert@gmail.com (Sven Ruppert)sven.ruppert@gmail.com (Sven Ruppert)© 2026 Sven Rupperthttps://svenruppert.com/img/sven-ruppert.jpgSven Rupperthttps://svenruppert.com/tags/browserless-testing/Fri, 21 Aug 2026 10:00:00 +0200From ClickUp to Vaadin — Part 2: The Build and the Balancehttps://svenruppert.com/posts/from-clickup-to-vaadin-part-2-the-build-and-the-balance/Fri, 21 Aug 2026 10:00:00 +0200sven.ruppert@gmail.com (Sven Ruppert)Sven Rupperthttps://svenruppert.com/posts/from-clickup-to-vaadin-part-2-the-build-and-the-balance/The second part: from the seven-view design of Part 1 to a running application in seventy-two commits, and an honest reckoning of the calculation that has tipped over. What the tool did well (drag-and-drop as ordinary Java, twelve lines from a Select to the hardened domain method, thirty-five stylesheet lines for a look of one's own) and what it did not (an import silently truncated at one hundred entries). Browserless view tests that reach into the real component tree, mutation testing as a check on tests written by the same assistant that wrote the code, and a balance sheet that names both columns of what a rented service actually costs — including the ability to leave.<![CDATA[

Where we stand

The first part ended with a model and a reservation. Anyone who has read it knows both; for anyone joining here, let the starting position be given in a few sentences, for without it much of what follows remains mere assembly instructions.

The point of departure was a flat list of tasks in a foreign tool whose actual structure did not reside in the system but in a naming convention. From it came a four-level ordering of content, and from a single status field, overloaded over the years with sixteen values, came three mutually independent dimensions: acquisition, editorial work and production. The history of each of these dimensions is not overwritten but appended, ordered by an ascending sequence number rather than by a timestamp. On this foundation there arose a domain concept, a catalogue of processes, and out of these seven views, whose design finally lay before me as an interactive model.

The reservation ran that a model which has to hold its own only against itself always wins. This second part is the redemption: the design becomes an application through which the real holdings pass.

Let the technical ground be named in advance, so that no guessing is required later on. The application is written throughout in Java, the interface with Vaadin; storage is handled by EclipseStore over an object graph, delivery by an embedded Jetty, and permissions by a slender tool of my own. Neither an application server nor a comprehensive framework is employed; where the JDK suffices, it suffices. No introduction to Vaadin’s building blocks is offered — they are presumed familiar, and what is interesting is in any case not which component displays something, but at which points the building blocks did not suffice.

What follows is therefore not a success story but a workshop report: the build in the order of the design briefs, the transfer of the model into the interface, the two views without a ready-made component, the bridge from the old system, verification without a browser, and at the end a reckoning that also names what went wrong.

The build, in the order of the briefs

Between the design and the running application lies that stretch about which articles of this kind usually keep silent — presumably because it is unspectacular. Yet it is precisely this stretch that decides whether the calculation claimed at the outset works out. The implementation followed directly on from the view briefs and comprised seventy-two commits in the end. The path there ran through three discernible phases: the building, the alignment, the hardening.

The building followed an order that emerged inevitably from the preceding stations. First the domain core with the status dimensions and the append-only history, then the aggregates together with the language rule as an invariant, after that the persistence, the permissions and the navigation scaffold. Only then came the views — individually, along the view briefs: the topic workspace, the language-version editor, the publication view, the editorial board, the history view, the publication places and finally the import. This order is no coincidence; it is the briefs worked through from top to bottom — with a single deviation: the publication view, the dramaturgical core, was pulled ahead of the editorial board. Anyone wondering what the detour via process catalogue and view briefs was good for will find the answer here: the implementation no longer had to invent anything.

One detail of this phase amuses me in retrospect. The domain core was first written with German identifiers —Statusverlauf,Statuswechsel,Sprachfassung — exactly as we had spoken about them in conversation. A refactoring of its own later tidied this up and translated the entire code into English, a good seventeen hundred changed lines across fifty-seven files. What appeared in the first part asStatusHistory had borne a different name before. The domain language of the conversation is simply not automatically the language of the code, and it is better to decide that early than late.

The model in the interface

So far I have spoken about the interface without showing it. That is unsatisfactory, for the interesting question is precisely how such a model reappears in an interface — and whether anything is lost along the way. Let us begin with the screen that carries the core of the whole.

The two-column publication view illustrated in the first part arises from a handful of lines:

java
FlexLayoutcolumns=newFlexLayout();columns.setWidthFull();columns.getStyle().set("gap","var(--lumo-space-l)");columns.setFlexWrap(FlexLayout.FlexWrap.WRAP);columns.add(acquisitionColumn(),productionColumn());body.add(columns);

More revealing than the layout, however, is what happens inside such a column:

java
privateDivproductionColumn(){Select<ProductionStatus>select=newSelect<>();select.setItems(ProductionStatus.values());select.setValue(publication.productionStatus());select.addValueChangeListener(e->{if(e.getValue()!=null&&e.getValue()!=publication.productionStatus()){publication.changeProductionStatus(e.getValue(),actor());repo.persist();render();}});...}

These twelve lines are the actual argument. The selection field is populated directly with the values of the enumeration — no transfer objects, no strings, no second maintenance of the states between interface and model. The event handler calls the hardened domain method directly; between the click and the appending to the status history there lies no network call, no serialisation, no second language. The type parameter moreover ensures that the compiler complains if a dimension were to receive a value that does not belong to it. What began in the first part as disentangling arrives here.

Publication overview of the running application — one row per publication, acquisition and production side by side

Figure 1: The publication overview of the running application — one row per publication, with acquisition and production state side by side.

Publication view of the running application — acquisition and production as two equal columns

Figure 2: The publication view of the running application — acquisition on the left, production on the right, each with its own state and history.

History workspace of the running application — status changes of all three dimensions in one list

Figure 3: The history overview of the running application — status changes of all three dimensions in one list, newest first, each row with a jump into its complete chain.

The editorial board across four steps

How such a view improves over time can be read particularly well from the editorial board. It became what it is today in four steps, and each step had a nameable trigger. The improvement requests were numbered just as the processes had been before, so that every commit message carries its occasion with it — a small amount of orderliness that pays off when retracing the path.

Step one — the requirement from the view brief. What was called for was a board showing the editorial progress of all parts at a glance, with one column per work state. Exactly that came about. Moving a card, however, was done through a selection field sitting on every single card:

java
Select<EditorialState>move=newSelect<>();move.setItems(EditorialState.values());move.setValue(part.editorialState());move.setWidthFull();move.addValueChangeListener(e->{...});card.add(title,info,move);

This satisfied the requirement, but it was not a board — it was a list with drop-down menus. The view brief had in fact provided for drag-and-drop, yet the first implementation took the shorter road — a behaviour I have observed in the assistant more than once: it fulfils the letter of the requirement, not its spirit, as long as one does not follow up.

Step two — the request for genuine drag-and-drop. The follow-up was raised as request F4, and here it becomes apparent what is meant by consistently doing everything in Java:

java
DropTarget<Div>dropTarget=DropTarget.create(col);dropTarget.addDropListener(e->onDrop(state));DragSource<Div>dragSource=DragSource.create(card);dragSource.setDragData(part);dragSource.addDragStartListener(e->draggedPart=part);dragSource.addDragEndListener(e->draggedPart=null);

No JavaScript, no event handling in the browser, no mediation between two worlds — drag-and-drop is an ordinary Java interface here. And both paths of interaction converge on the same domain method, which prevents two routes from drifting apart:

java
privatevoidonDrop(EditorialStatetarget){if(draggedPart!=null&&draggedPart.editorialState()!=target){draggedPart.changeState(target,actor());repo.persist();draggedPart=null;refresh();}}

It is worth noting that the selection field was deliberately retained at first; the source code expressly recorded it as an equally capable, accessible fallback for anyone unable or unwilling to drag with a mouse.

Step three — the request for a second form of display. In daily use it turned out that the board becomes unwieldy with many parts and that a tabular view of the same data was missing. With this addition the selection field on the cards became dispensable, since the table offered a mouse-free route in any case. The third step therefore did not merely add something, but took something away: the selection field disappeared together with its import, and the card has since carried only title, part and markers. It belongs to the honesty of this account that such a removal comes more easily when an assistant carries the change through without appreciable effort; by hand I would probably have left the working selection field where it was.

Editorial board of the running application — columns per editorial state, cards without the dispensable select

Figure 1: The editorial board of the running application — one column per work state, the cards without the selection field that had become dispensable.

The same data as a table — grouped by editorial state

Figure 2: The same data as a table — grouped by work state.

Step four — the objection of an analysis tool. The last step did not come out of conversation. The board kept the filtered parts cached in a field in order to share them between the column and table views — convenient, but a piece of state that can go stale and which the static analysis rightly complained about. In its place came a method that recomputes on demand:

java
privateList<Part>filteredParts(){PublicationsFilterfilter=PublicationsFilter.current();returnrepo.issues().stream().filter(filter::matchesTitle).flatMap(i->i.parts().stream()).toList();}

Four steps: a list with drop-down menus became a board, the board became a leaner board with two forms of display, and in the end a cache disappeared that could have attracted defects. Further requests followed later — compound search filters and an optional AND or OR combination of tags — yet the pattern remained the same. None of these steps is remarkable in itself. What is remarkable is that they took place at this density, for the fact that an improvement barely weighs anything at all decides whether one makes it.

Finally, a small matter that pleases me, because it carries the method from the first part right into the source code. Every view names in its description the processes it serves:

java
/** * Served processes: P0008–P0013. */@Route(value=PublicationView.NAV,layout=MainLayout.class)@VisibleFor(AuthorizationRole.USER)publicclassPublicationViewextendsComposite<VerticalLayout>implementsHasUrlParameter<String>,I18nSupport{

Anyone wanting to know in six months’ time why this screen exists will find the answer where they would look anyway.

The seam: a look of one’s own in thirty-five lines

Now to that seam which I named openly at the end of the first part: the draft was a free front-end mock-up, and Vaadin brings its own visual language. How does one close that? The answer turned out to be smaller than I had expected. A single commit brought the IBM Plex fonts and the colour palette into the application, and it comprised thirty-five changed lines in a single stylesheet. This is possible because Vaadin’s Lumo styling can be redefined through CSS custom properties — one exchanges typeface, colours and corner radii without touching a single component. The seam was real, then, but it was narrow. Whoever wants a look of their own can have it; they need only know that it comes about in the stylesheet and not in the Java code.

The bridge: the import as an ETL

Between the old system and the new one stands a bridge, and it is of a different kind from everything built so far. It does not belong to the application but to the transition. It is needed for as long as data resides in ClickUp, and it disappears the moment that ceases to be the case. A throwaway piece, then — yet one on which the entire migration depends, because not a single correspondence between source and target arises of its own accord. That is precisely why the import is built as an ETL rather than as a script that runs once and hopes.

The value of the tripartite structure lies in the strict separation of the three acts. Extraction fetches the task list over the network, writes it unaltered to disk, and is thereby finished. Transformation and loading then work exclusively against that local copy and may be repeated at will. This is no formality but the heart of the matter: the interesting work resides in the transformation, and transformations are rarely got right at the first attempt. Anyone who reaches across the network for every attempt turns a swift loop into a laborious affair and, into the bargain, surrenders to the rate limits of a foreign interface.

The raw copy consists of two files, the JSON document and a note recording the moment of extraction. What is remarkable is what gets preserved: every field of the source, not merely those the transformation currently consumes. That restraint is deliberate. What one does not need today cannot be retrieved later, once the source has been switched off. The store itself remains deliberately undemanding — it is handed its directory, and the timestamp along with it, rather than consulting a clock, in which it follows the domain model’s abstention from embedded time. On the network side, the JDK’s HTTP client suffices; no framework is required at any point.

The actual act of transformation is the one towards which the first part of this account was working: the distribution of the conflated status field. The analysis has become a mapping table, and the mapping table an executable case distinction. And here a limitation must be named openly, one the migration cannot resolve. Only the editorial dimension is populated. Production and acquisition were never recorded independently in ClickUp, and no transformation invents what was never gathered. The parts taken over therefore begin in the neutral initial states of the two other dimensions. The disentanglement acts forwards, not retrospectively — it provides the model in which the distinction can be maintained from now on.

Two decisions at this juncture strike me as the most instructive in the whole module. First, an unrecognised status value does not drop out but drops into the backlog. A record that cannot be mapped is not lost; it lands visibly where somebody will have to take it up again. Second, the report of a run carries not merely tallies but a frequency-counted mapping of the form “source value became target state”. This turns the import into an instrument of inspection: one reads off which of the sixteen ClickUp values fell how often onto which editorial state, and holds the mapping table devised at the desk against the actual data.

That leaves repeatability, and it rests on a single field. Every case taken over records its origin, the identifier of the ClickUp task. Should loading encounter an origin already recorded, it passes the record over. A second run therefore creates nothing but merely reports what it skipped. Only this property makes the bridge serviceable in daily use: one imports, examines the distribution, improves the mapping, imports again — and need tidy nothing in between.

The self-description written into the module puts it exactly: a throwaway module in production, a workhorse in development. The reckoning becomes wholly honest only later, however. Extraction walks the pages of the foreign interface in a loop, and the fact that it did not do so at first was the most consequential error of the entire undertaking. That it was noticed at all is owed to the raw copy: because the extract lies complete on disk, one can count what arrived and compare it with what ought to have been there.

Verification without a browser

Every station of this account so far runs towards the same uncomfortable question, and I have only brushed against it until now. If an assistant writes the code and then writes the tests for it, what do those tests actually prove? They check what the assistant understood. A misunderstanding propagates from the code into the test, where it is not exposed but confirmed. Whoever works this way and trusts green bars has built themselves a machine that agrees with them.

First to the craft side, for without it there would be nothing to verify at all. A Vaadin interface can be tested without a browser: the view is created in the same runtime in which the check runs, and one reaches into the real component tree rather than into rendered HTML. No browser, no remote-control protocol, no waiting seconds — and above all no brittleness with respect to labels and positions. Such a check looks like this:

java
@Test@DisplayName("renders both lifecycle columns with their initial states")voidrendersTwoColumns(){UI.getCurrent().navigate(PublicationView.class,vId.toString());assertEquals("Publication",$view(H1.class).first().getText());List<String>spanTexts=$view(Span.class).all().stream().map(Span::getText).collect(Collectors.toList());assertTrue(spanTexts.contains("ACQUISITION"),"left column is Acquisition");assertTrue(spanTexts.contains("PRODUCTION"),"right column is Production");assertTrue(spanTexts.contains("REQUESTED"),"acquisition starts at REQUESTED");assertTrue(spanTexts.contains("PLANNED"),"production starts at PLANNED");assertEquals(2,$view(Select.class).all().size(),"one advance-Select per dimension");}

What is remarkable here is less the technique than what is actually being checked. The claim that carries this entire article — two independent lifecycles on a single object — has at this point become a guarantee that is recomputed with every build. Were someone to remove one of the two columns, the test would fail. The disentangling from the analysis is thus not merely modelled and drawn, but pinned down.

Equally revealing is the preparation of such checks. They build their own body of data from scratch — a publication place, a topic, a part, a language version, a planned publication — and store it in a second, purely in-memory persistence implementation that stands alongside the file-based one. That an object graph can be replaced by a stand-in so easily is a quiet advantage of doing without a database: there is no schema to create beforehand, and no server to start.

By now the undertaking comprises sixty-one test classes with close to three hundred checks; twenty-one of those classes are browserless view tests. And here the opening question returns: these figures impress, but on their own they prove nothing. The truncated import from the previous station was surrounded by tests that all ran green.

This is why one needs means of verification that come from outside — that do not know what the assistant meant. The first is static analysis, which found seventeen complaints in the code of the publication management: missing serialisation identifiers, mutable collections handed straight out. None of it was an error of thought, all of it was craftsmanlike negligence, and not one of the tests would ever have noticed.

The second and more effective means is mutation testing, and it answers precisely the question at issue here. It deliberately alters the code in many places in small ways — inverts a condition, swaps a return value, removes a call — and then runs the tests. If no test notices the alteration, one has a test that passes but secures nothing. Where the usual coverage measurement only counts which lines were executed, mutation testing asks whether their behaviour is specified at all. For tests that come from the same instance as the code, that is the only honest counter-check.

How this is arranged in the project is, to my mind, the actual lesson of this chapter. A single global threshold would be useless, because it either overtaxes the interface or undertaxes the core. Instead, a dedicated file keeps per-package floors, and its comment states the expectations openly: the load-bearing security and domain packages lie between seventy-five and ninety-five per cent, the view packages deliberately far below. The floors are deliberately set two or three points below the measured state, so that ordinary refactorings do not trip them while a genuine regression does; they may be raised only after a sustained better state, and lowered only with a written reason.

Such a reason does in fact stand in the file, and it is more instructive than any success report: the overall floor was lowered when new interface components were added that generate many mutants in pure assembly code — code, that is, which plugs components together and in which there is little to assert. That is the honest way to handle a metric: not to flatter it, but to write down why it moved.

Levels of verification and what each of them catches

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.

]]>JavaVaadin