Building a platform from zero, at speed, without losing control of it

01In summary

One developer. A product-independent portal framework and a full business platform, built at the same time, from nothing. Measured on 2026-09-07: 82 independently versioned packages, 4,697 commits, 2,045 released versions, 214,051 lines of source and 137,518 lines of tests — across 95 active working days.

Those numbers are not the point of this document. Generating a lot of code quickly stopped being remarkable some time ago. The interesting question is the one immediately after it: what stops a codebase produced at that rate from becoming unmaintainable within weeks?

The answer has two halves. The first is a small set of mechanisms — ten of them — individually unglamorous and collectively decisive. State lives on disk rather than in a conversation. A unit of work is sized to one session and is never left half-done. Architectural decisions are locked and may not be reopened. Claims are not accepted; evidence is. The schema is a contract and a gap in it is a change request, not an improvisation. Work streams have hard boundaries. Tests are the ratchet that makes it safe to change code nobody remembers writing.

The second half is organisational. What runs is not one assistant taking dictation but eight standing agent roles with fixed scopes across two machines — the ones that build kept separate from the ones that integrate and verify — of which only two ever address the human. Behind them sits a planning cascade of 1,067 documents and an audit matrix that checks each artefact against the one it came from.

The method has a price, and this document states it: roughly one line of documentation for every line of source. That ratio is not overhead around the work. It is the work — it is the memory that makes the next session possible.

02The starting point

Greenfield, in the strong sense: no existing framework, no team, no inherited codebase to extend. The target was a business platform for a service- and asset-management vertical — customers, products, work documents, assets, projects, tickets, finance — deployed for a real integrating party who would be waiting for builds.

The decisive constraint was that two things had to be produced at once: a product-independent portal framework, and a business platform composed from it. Building either alone is ordinary work. Building both together means every framework decision is immediately stress-tested by a real consumer, and every product requirement pushes back on the framework. There is no comfortable phase where the foundation is finished and stable.

The second constraint was the shape of the workforce: one human, and AI agents doing the building. That changes the economics of a project in a specific way. The cost of writing code collapses, and the cost of knowing what is true about the code becomes the binding constraint — which is a different problem, and the one everything below is an answer to.

It also changes what "one developer" means. Headcount stayed at one; the structure did not. What emerged was an organisation of agent roles with separated responsibilities, its own planning cascade and its own audit levels — described in sections 5 and 6. Reading the rest of this document as an account of one person typing faster would miss the point of it.

03The question that actually matters

AI-assisted projects fail in recognisable ways, and none of them are about code quality in the usual sense.

Amnesia. The assistant does not remember yesterday. Anything agreed in conversation and not written to disk is gone at the next session. A project run this way drifts, because each session starts from a slightly different understanding of the world.

Compulsive re-architecting. Given a settled decision, a capable assistant will cheerfully reopen it and propose something better. Each proposal is defensible. The aggregate is a project that redesigns itself weekly and finishes nothing.

Confident wrongness. An assistant reports success. Without an independent check, a status log fills with claims that were never true, and the divergence between the log and the disk is discovered much later, expensively.

Add speed, and a fourth appears: blast radius. At several releases a day across dozens of interdependent packages, a change in a shared layer can break a consumer that nobody looks at for a week.

04The method: ten mechanisms

These are not principles in the abstract. Each one is implemented as a specific artefact in the repositories, and each is quoted below from the project's own working documents.

05The organisation

"One developer with AI assistance" is accurate about headcount and misleading about structure. What actually runs is a small organisation: eight standing agent roles with fixed scopes, spread across two machines, of which only two ever address the human.

The split between the machines is the important part. One machine builds; the other integrates what was built, deploys it to a test environment, and runs the integration tests against it. The party that produces a thing is never the party that certifies it works — a separation that is ordinary in an engineering organisation and almost never reproduced in an AI-assisted one.

Only two leader roles talk to the human, over chat: the framework integrator on one machine and the frontend leader on the other. Everyone else coordinates agent to agent. This is a span-of-control decision, and it is what makes the arrangement tractable for one person: the human answers questions of product and priority and is not the message bus. A setup in which every agent reports to the human does not scale past about three of them, which is why most attempts stop there.

Below the session, work fans out again. Every role decomposes its own work to purpose-briefed subagents — one per task, each given only what that task needs. The session therefore remains the unit of accountability, as mechanism M2 requires, while the subagent becomes the unit of execution. The dedicated auditor role works the same way, and so does the checking below it: functional completeness is verified against the concepts by a role and by subagents that did not produce the work.

06The cascade and the audit matrix

Nothing is built from a conversation. Every problem gets a concept; every concept yields epics; every epic yields issues and implementation plans. Code is written against an implementation plan, not against a request.

A cascade on its own would only be paperwork. What makes it load-bearing is that every adjacent pair of artefacts is audited against the other, on three independent axes.

The functional-coverage axis is the one most projects lack. It asks a question that test coverage alone cannot answer: not "is this code tested" but "is every function the concept promised actually present, and is it tested". A codebase can sit at full line coverage and still be missing half of what it was supposed to do.

Evidence takes three forms: documents, reports and screenshots. Screenshots captured during testing are themselves reviewed by auditor subagents — one agent checking another agent's visual evidence. Those captures are internal proof, never illustrations, which is why none of them appear in this document.

07Building the factory

A method needs a substrate, and the substrate was built too — alongside the product, not bought.

Everything runs in containers, on both machines — including the editor servers the agent sessions themselves run inside, which are reachable and supervisable from a browser. The consequence is that a session's environment is reproducible and disposable, rather than a machine someone configured once and can no longer rebuild.

Nothing is released untested in its real form. Before a release leaves the development machine it is exercised container-in-container, so the artefact that ships is the artefact that was tested — not a build that happened to pass on a developer's host.

The release chain has fixed gates. Unit and end-to-end tests run at release; the release publishes to both registries, source and container; and after every integration there is a test deployment and an integration test on the other machine. No step is skipped because the change looked small.

Around that sits the tooling built to serve the method: an orchestration service running agent workflows through a job queue, an abstraction layer exposing the coding assistant as a callable API rather than a terminal session, and a self-hosted CI/CD platform designed for coding agents rather than adapted from a human workflow.

This is the part most accounts of AI-assisted development omit, and it is a substantial share of the effort. The tooling is the method in executable form: a rule that lives only in a document gets violated, while a rule encoded in a pipeline does not.

08The architecture the method forces

The architecture is largely a consequence of the method rather than an independent choice. Small bounded contexts for agents implies many small packages. Versioning as the integration protocol implies independent release pipelines. Seams-first implies explicit layers.

The boundary map matters as much as the layer map. Concurrent work streams are kept apart by explicit rules, and they meet only at published version numbers.

09The time axis

The core platform's first commit is dated 2026-03-18 and its most recent 2026-09-07: 173 elapsed days, of which 95 carry commits. That is 49 commits per active day, by one developer.

The more interesting measurement is not the rate but the shape. Classifying every commit by its conventional-commit prefix, month by month, shows the project changing phase without anyone having to assert that it did.

Release cadence tells the same story from another angle — and shows that the layers move at deliberately different speeds.

10What was built

Kept short on purpose: this is evidence for the method, not the subject of the document.

The delivered surface: 765 API operations across 439 paths — a public customer-reachable API, not a backend-for-frontend; 129 tables and 16 views in a schema governed by numbered change requests; 4,181 translation keys in two complete locales; and 52 catalogued use cases across 6 actor roles, each captured with evidence rather than asserted.

11How quality held at that speed

There are 1,263 frontend and 2,452 backend test cases. More telling than the totals is how the end-to-end suite is divided:

The frontend test health was closed out with two purpose-built scanners rather than by self-assessment — one measuring coverage against a per-surface rule set, one measuring strictness: whether a test actually asserts something, or merely checks that an element exists. Final state: 1,189 tests, 488 of 488 coverage slots filled, 0 strictness violations, and a full-suite run of 1,092 passed, 0 failed in 42 minutes.

Both scanners are committed and re-runnable against the repositories they measure. That is what separates a quality measurement from a quality impression: the figure was produced by a tool rather than an opinion, it can be reproduced on demand, and a later run is free to contradict an earlier one.

12The stabilisation phase

Most accounts of fast development stop at the point of first delivery. The part that decides whether a system is worth owning comes after it, and it is measurable.

Two defect streams ran in parallel. An external integrating party, testing a deployed build against real data, reported 17 issues; 16 were genuine and were fixed, and 1 was demonstrated not to be a defect at all — a difference in test fixtures — and was reported back as such rather than quietly closed or invisibly "fixed".

Internally, integrated end-to-end runs raised 34 observations. Only 17 survived triage as real defects; 15 were fixed, one was consciously declined, one was reclassified. Half of the raised observations were not defects — which is precisely why the loop opens with a verify-first triage rather than a fix. As the project's own discipline document puts it, a false fix on a non-defect is itself a regression.

Recording defects instead of fixing them

During a backend coverage sweep, 14 latent defects were found and deliberately not fixed. Each was recorded with evidence, and each carries a characterising test that asserts the current, wrong behaviour — so the test turns red the moment someone fixes the defect. The rationale is that a coverage sweep and a fix round are different activities with different risk profiles, and mixing them makes both harder to review.

On the frontend, 32 of the 289 mock-mode specification files are named after the specific defect they lock down. A fixed bug that has no test is a bug scheduled to return.

13Measured against an external yardstick

Self-assessment is worthless at this scale, so the platform was audited against two independent external axes: a process framework (the APQC Process Classification Framework) and a set of established open-source ERP and CRM systems used as data-model baselines. Only a schema table, an API endpoint or a module manifest counted as evidence. Self-report counted for nothing.

The verdict was unflattering in a useful way. What exists is a service- and asset-management system with a strong document chain — not a general ERP and not a CRM. The document engine and the platform layer measured above the open-source references. The top half of the sales funnel — lead, qualification, opportunity, stage, forecast — measured at zero.

These numbers are published here alongside the favourable ones on purpose. A case study that reports only its wins is not evidence of anything; the willingness to publish 33% is what makes the rest of the document worth reading.

14The composition proof

The strongest claim in this case study is not about size or speed. It is that the framework is genuinely product-independent — and that claim has a control case.

Two applications run on the same framework. One is the full business platform: dozens of business modules, a complete document chain, a public API, multi-tenant access control. The other is a reference application that composes the same shell and a handful of generic modules with, in its own words, no custom code beyond configuration — roughly a hundred lines. Same framework, same shell, same plugin runtime; radically different products.

The commercial consequence is the point: a subsequent product is not a rewrite, it is a module selection. A different composition of the same layers yields a differently-scoped system — service management, asset management, a sales-document pipeline — without touching the shared layers that all of them depend on.

15What it proves, what it costs, where it stops

The price

The core platform holds 214,051 lines of source and 180,756 lines of documentation. Roughly one to one.

That ratio is the honest cost of the method, and it runs against the common expectation that AI assistance means writing less prose, not more. It does not. When the workforce has no memory, the written record is the memory — the status files, the decision logs, the change requests, the evidence trails, the working guides. Remove them and the mechanisms in section 4 all fail at once. Anyone adopting this method should budget for that, and should expect the documentation to feel disproportionate right up until the first session that would otherwise have started from nothing.

Where it stops

The system is not finished, and the project says so in its own tracking. A per-module deferred list names every capability intentionally left out, with the schema objects it would need. A ratified version roadmap sequences the remaining work. Fourteen latent defects are recorded and unfixed by design. The external audit names six capability gaps in priority order, beginning with service-level agreements and the sales funnel.

None of that is a disclaimer. A project that can enumerate precisely what it has not built is demonstrating the same discipline as one that can prove what it has.

What the method does not solve

It does not remove the need for judgement — the triage figures in section 12 show that half of all raised observations required a human decision about what was actually true. It does not make a single developer equivalent to a team; it makes one developer able to hold a system of this size in a form that survives their absence. And it says nothing about whether the product is the right product: that question is answered in section 13, by an audit, and the answer was partly no.