Contracts make apps composable
The tenth application should cost less than the second, because the interface was decided once and is enforced by test. That is the argument for the architecture, not a measurement — I have never timed it.
The method
How one person builds ten applications
Not by typing faster. By writing the rules down first, and then refusing to break them when it would be convenient.
Everything on this page exists as a file in the public repository. The documents are in German — they were written to be used, not to be shown — and the quotes below are translated, with the source named each time.
Chapter one
Written law before code
Before there was an architecture there was a file of binding working rules, and every session since has had to honour it without being reminded. It is a short document. It is also the reason the system did not drift apart while a single person built ten applications.
The most useful of those rules is the one about honesty, because it constrains the software and not just the author. A value that was never measured is reported as unmeasured. It never becomes a zero, and a zero never becomes a claim.
Law 2 · honesty“Honest assessments. Motto: we find the best way together. Where there is doubt, say so openly — do not talk it up.”
Law 4 · quality“Code quality is the highest law: structural, professional, functional, efficient, absolutely clean and comprehensible.”
The English sentence the repository README uses for the same rule: “If a value was never measured, the system says so instead of showing a zero.” That rule governs this website too — which is why there is a page stating how the figures this site leads with were counted →
Chapter two
Contracts before features
A feature is a thing you build once. A contract is a thing that builds the next nine.
The app contract fixes what every application must answer: health, manifest, summary, settings, account, vault, audit, actions, and an MCP tool server. Meet it and the dashboard picks the app up automatically; the assistant can reach it without a new integration.
What makes it a contract rather than a wish is that it is checked by machine. A conformance module runs inside the test suite of seven of the ten, so an app that drifts fails its own build. The specification is blunt about the hierarchy: where the prose and the code disagree, the code wins.
# the scaling mechanic, in one line
write the contract
→ the app appears in the dashboard
→ the assistant can reach it
→ its tests enforce the contract
→ appkit upgrades reach it for free
docs/16, enforced by
appkit/conformance.py.Source: docs/16_APP_VERTRAG_SPEC.mdChapter three
Research before decisions
Independent research is not an optional flourish here; it is Law 3 — deliberately at critical points, and regularly in between. The protocols are written down and kept: research waves for the network, fundamental research and metric studies for the trading side, a strategy catalogue that records what was rejected as well as what was adopted.
Keeping the rejected options is the part that pays off later. Six months on, the question is never “what did I choose?” — it is “did I already look at this, and why did I say no?”
Law 3 · research“Regular independent research — targeted at critical points and generally interleaved, so that a maximally optimised product emerges.”
Law 9 · no drift“There must never arise a state in which code, plan and documentation diverge; outdated references are actively removed on update.”
Chapter four
An orchestra of AI build chats
This is the part that is hard to see from outside, so here it is plainly. One human directs. An administrating chat holds the overall state and decides what happens next; separate build chats do the actual work, one work package at a time. They do not talk to each other. They talk through written hand-over documents — the same artefact type as the contracts and the laws.
That hand-over document is the real invention. It carries the brief, the constraints, the forbidden moves and the acceptance gate, so a fresh chat with no memory of yesterday can pick up a package and finish it to the same standard. Work packages that are independent run in parallel, each in its own working tree, so two builds never fight over one checkout.
Law 10 · three tiers“Model vigilance — three tiers: assistant tier, builder tier, architect tier. Work packages are graded in advance. Stay honest: no needless promotion, but no risky demotion either — when in doubt, one tier up.”
- Assistant tier — only for packages where a clean reference pattern already exists, green tests cover it, no architectural decision is needed and nothing security- or money-critical is touched.
- Builder tier — the default for ordinary construction work.
- Architect tier — subtle architecture and schema logic, the AI core, large autonomous overnight runs, deep security reviews, hard bugs.
The first execution of any new pattern is never given to the assistant tier. That rule is written down, not improvised.
Chapter five
The route one work package takes
The chapter above names the actors. This is the route they run on: what happens to a single package of work between the first written line and the merge. Every stop is a rule with a document behind it.
-
The brief exists before the work does
A package starts as a file: the goal, the commit it starts from, the moves that are forbidden, and the gate it has to pass before it may call itself finished. It is written for someone with no memory of yesterday, because that is who picks it up.
-
The lane is part of the record
Independent packages run at the same time, each in its own working tree on its own branch, so two builds never edit one checkout. That part is checkable rather than claimed: the contracts in the repository name the tree, the branch and the tier in their status header, so a document can be read back to the lane that produced it.
-
Permission is given before the night, not during it
An unattended run carries its permissions in writing: what may be restarted, what has to stay green, what it must not touch, and what has to be on the table in the morning. The working rules fix the order — the plan is read back once, a human confirms, and only then does the machine work through alone.
-
Clean twice in a row, or it is not finished
The closing block of a package is a loop rather than a checkbox: run the checks, review what they touched, repair what they found, then run all of it again — and the package counts as done only after two consecutive clean passes. One clean pass is also what it looks like when a check never reached the thing it was meant to read.
-
It ends in a document, not in a conversation
The last thing a package produces is a hand-over sheet: what was built, what was measured, what stayed open. The next chat starts from the sheet. A hand-over that lives only in a conversation is gone when the conversation is.
-
The overview stays with the person directing
After a large package the rules require a full control round over everything, and before that round a systematic listing of what the systems now do — so the overview is read off the parts instead of taken from a summary of them.
Three stops on this route used to link a worked example — a work package, its closing block, a hand-over sheet. Those files sat in the public extract until 6 August 2026, when it was cut back to a curated set of documents. The examples are not in that set, so the links are gone rather than pointing at nothing: what is published now, and what was →
This website was built the same way. It is a work package like any other: written up first, built in its own working tree, held to a gate of named scripts — and not called finished until that gate came out clean twice in a row.
Chapter six
Human gates on everything irreversible
The network’s assistants observe and propose. Effect requires a human, at the security tier that matches the act. Money, publishing and deletion are the three places where that rule is not negotiable — and they are exactly the three places where an autonomous system is most tempting and most dangerous.
It is enforced structurally rather than by discipline: the proposal endpoint and the approval endpoint are different endpoints, the approval demands a fresh authentication, and both sides land in an audit log that the proposing side cannot edit.
Law · human gates“Nothing irreversible without a human. Money, publishing and deletion sit behind explicit gates. The trading fleet proposes; a person decides.”
Law 11 · calm before haste“When in doubt, check a second longer or think it over once more before acting. ‘Quickly, please’ never suspends care. The structure carries — not the hurry.”
Chapter seven
Why it goes fast
The speed is not the point, but it is the question everyone asks, so here is the honest answer — six parts, none of them magic.
appkit prevents drift
One shared library instead of ten divergent copies. A security improvement lands in every application that imports the library, in one commit.
Laws prevent rework
Most lost time in a project is spent undoing something that should not have been started. Written rules are cheaper than reversals.
AI delivers volume
Build chats produce code and documentation at a rate a single person cannot. That is the part everyone already knows.
The human delivers judgement
What to build, what to refuse, when a thing is good enough, and when to stop. No model has been given that decision here.
And it is checkable
The pace is not a claim on a website. It is dated documents in a repository — night runs, system checks, audits, from 8 June 2026 onward.