Builds

Three systems, built alone.

Evidence of range rather than products for sale. In each case the method is the same and the constraint is real: no account, no server, and every claim had to be provable rather than asserted.

01

local-first capacity planning

Senna

A planning system that treats a week as a budget rather than a list. Work is entered as items with estimates, then placed into capacity blocks; the app measures what was actually completed against what was planned, so the plan and the week can be compared rather than remembered.

It runs on the machine. An Electron shell over a local SQLite database — no account, no remote database, no sync to reconcile. The design constraint was that the tool must work on a laptop with no connection and no server behind it.

It plans to a deliberate 60% floor rather than a 100% target, because a benchmark you keep missing gets abandoned. The remaining capacity absorbs the interruptions that no estimate contains.

54,254lines of code

104commits

618tracked items · 63 epics

Fig. 01 — how the week is planned, then measured

Architecture and what it solves

Fig. 01b — the three layers behind the loop

What this solves that off-the-shelf tools leave open

Commercial planners are built for teams: seats, accounts, a server, and a sync model that reconciles concurrent edits. A single-operator plan needs none of that and pays for all of it — in latency, in subscription, and in who holds the data.
They model work as tasks with a status. Capacity is not a field, so ‘what fits in this week’ stays a judgement rather than a constraint the tool can enforce.
They optimise for utilisation. Planning to a 60% floor is the opposite bet: the schedule has to survive contact with a real week, or it gets abandoned and the measurement becomes fiction.

The measurement is the product: a plan you can hold against the week that actually happened, rather than a schedule that only records intent.
Local-first shaped the architecture from the first commit — it is not a feature added to a hosted design.

02

a generalised idea-capture system

RCS

A capture system that stores not just a belief but the terms on which it would expire: what would falsify it, how likely that is, and how much warning it would give before it failed.

Entries form an append-only log, so the record shows when a position changed and what changed it — not only where it ended up. A conclusion without its revision conditions is a guess with good formatting.

The subject matter it holds is private. The pattern is general, and that is the reason it is described here.

14,299lines of code

14mapped flows

280code-traced steps

Fig. 02 — a position and the terms that would retire it

Architecture and what it solves

Fig. 02b — input, store and query

What this solves that off-the-shelf tools leave open

Note tools store what you concluded. The mainstream ones have no field for the conditions under which a conclusion should be revised, so the archive cannot tell you which of your positions has gone stale.
Forecasting platforms do track predictions against outcomes, but for public scoring rather than private belief maintenance. This is the private version: your positions, your falsifiers, your revision history.
Because the log is append-only, being wrong is recorded rather than edited away — which is the only version of the record worth consulting later.

Most note tools store conclusions. This one stores the conditions under which a conclusion should be revised.
Fourteen flows were mapped from the source and 280 steps traced, so the system's behaviour is documented rather than remembered.

03

the capture pipeline

Anzu → Ashurbanipal

A browser capture extension feeding a private library. A document is identified by the hash of its contents rather than its filename, so files can be moved or renamed without breaking the record that points at them.

Everything reads through database connections opened read-only at the driver. That is not a convention the code is expected to respect — it is proven by a test that attempts a write and expects to fail.

Raw capture and catalogued knowledge are kept apart: the extension appends, the library classifies, and neither rewrites the other.

13,037lines of capture

~690catalogued documents

~3,800concepts · 30k typed relations

Fig. 03 — capture to catalogue, and the read-only boundary

Architecture and what it solves

Fig. 03b — browser, identity, library, guard

What this solves that off-the-shelf tools leave open

Read-it-later tools and reference managers identify an item by its URL or its filename. Rename or move the file and the record points at nothing, so the archive degrades every time it is reorganised.
Most keep one layer: the captured article and its notes are the same object. Separating raw capture from a derived catalogue means the derived layer can be rebuilt rather than repaired.
Read-only access is usually enforced by the application’s own code paths. Enforcing it at the driver means a future bug cannot write through the guarantee.

Identity by content, not by location — the same principle as evidence that survives a reorganisation.
A read-only guarantee enforced at the connection, not by discipline.

What they share

A single method and a single constraint: each system had to be usable without an account, and each had to prove its own claims rather than assert them. That is the same discipline the engagements on this site are built on, applied to software I own outright.

the offer →