A child document: its overrides on the left, the canvas, the properties panel on the right.

Why

Looking for work and for a school means sending the same résumé dozens of times, each one slightly different: another title, a project moved up, a line rewritten for one company. Duplicating files works for a week, then the copies drift and nobody knows which one holds the latest phrasing. And the tools that make a CV look good (Figma, Canva) export PDFs that applicant tracking systems read as scrambled text, or not at all.

So the brief was short: write once, branch cheaply, and export a PDF a naive parser can read in order. It's now what I use for my own applications.

The premise underneath: a résumé is basically a data set (roles, dates, skills, links), and the tool is an interface to manipulate it. So data and layout are kept apart. The same content can be reordered, branched or exported without being rewritten.

First attempt: blocks and variables

The first version, in mid June, borrowed the mental model of a design tool. Documents laid out side by side on a canvas, a library of blocks you dragged onto a page, presets with on/off flags, per-instance overrides "Figma-style", then a global registry of variables (name, contact, section titles) that fields could bind to.

Each idea made sense alone. Together, they made two reuse systems running side by side, binding states to read, and edits bundled behind Overwrite / Push / Cancel. Before changing a sentence, you had to know where it lived: in the block, in the variable, or in this page's override. That's a design-system problem leaking into a writing tool, and it was the wrong one to hand to someone tailoring a CV at midnight.

Second attempt: parents and children

Most of those directions were design-driven, and they ended in a bloated proposal. On July 8, I forked the project. One thing survived from the first version: the canvas, where several documents open side by side, to compare a variant with its parent or read a letter next to its résumé. Everything else gave way to a single idea.

A résumé next to its cover letter on the canvas.

A document is either a reference, complete and concrete, or a child of another document. The child stores nothing but its differences: an ordered list of overrides (change a field, add an entry, remove one, reorder). That list is both what makes the child different and its history.

Name, contact, accent and section titles stopped being variables. They're fields of the reference, inherited and overridable like everything else. Three levels cover real use: a base résumé, a variant per kind of role, one per company. Cover letters live in the same tool and follow the same model: a base letter, then a child per application.

A few decisions made it usable:

• The diff is readable. An Overrides panel lists a child's changes by where they land, or by when they happened, each with its before → after.
• Every change can go both ways. ↺ reverts one override; ↑ pushes it one level up, so a good rewrite made for one company can become the base for all.
• The canvas stays clean. No permanent badges on the page: hovering a row in the panel highlights exactly where that change lands.
• Parents don't move under their children. Editing a document others inherit from stages the change; nothing reaches them until you push.
• What a child adds is one override, not a pile of fields. Otherwise you could push the icon of an entry the parent doesn't even have.

Hovering a row of the Overrides panel highlights where that change lands.

Editing a document others inherit from: the change is staged until pushed.

Iterations

Most of the work after that was taking things out. The floating format bar became light Markdown typed in place, the Save button became autosave, drag-to-add became a + in the panel, and every piece of text became editable straight on the canvas, with the panel left for structure.

The export shaped the look more than taste did. One column of content, because side-by-side columns interleave lines when a parser extracts them. Typography carries the hierarchy, not boxes.

Storage follows from the premise. Documents are plain data: kept in the browser by default or, in Chromium browsers, written as JSON files in a directory you pick. In that mode an agent can edit them directly, to tailor a résumé to a job offer for instance, and the open app picks the changes up.

In July it became hostable, under one rule: a released version (the beta aside) never changes under the people using it. Each one keeps its own subdomain, data and frozen format, while I break things on a nightly next to it, so there are no migrations to write.