What it is, in plain terms
Build is a private, in-development platform for governing software projects — not writing code, but keeping track of what a project actually is, is supposed to be, and has evidence of being. It records a project's lifecycle from an idea through delivery, keeps requirements linked through to the design, work and tests that satisfy them, works out what else is affected when one part of a project changes, tracks budgets and capacity against the plan, and only lets a stage advance when the evidence a gate demands genuinely exists rather than when someone has said it does.
It is not a general project-management tool with a governance label attached; the governance is the point, and most of what the platform does is in service of being able to say, honestly, whether a project is where it claims to be. It is not released. There is no public address to visit, and by the owner's own standing instruction, it will not be deployed to production until it can pass the same evidence-gated standard it applies to the projects it tracks — which, as of today, it cannot yet.
Why I built it
I wanted to find out whether the discipline that "evidence-gated" implies could actually survive being applied to a real, growing piece of software, including the software doing the applying. It is easy for a status report to describe a project as further along than it is — a form gets filled in, a checkbox gets ticked, and nobody goes back to check the evidence behind it actually exists. I wanted a platform that structurally could not do that: where a gate that asks for evidence only passes when evidence is attached, where a requirement that cannot be traced to a test says so rather than being silently dropped, and where the platform's own account of its own progress is held to the same rule.
Partway through, the project’s own phase history read as though the platform were nearly finished. It was not, and working out exactly how not — measured, not guessed — became as much the point of the project as the platform itself.
The problem underneath
Software governance tools tend to fail in a specific way: they get very good at recording what people say is true, and offer nothing that checks whether it is. A gate marked "evidence attached" can mean a genuine artefact was reviewed, or it can mean a text field was typed into once and never revisited. A requirement marked "verified" can mean a test actually exercises it, or it can mean somebody believed it did.
The gap between those two things tends to be invisible until something goes wrong, at which point the record turns out to have been agreeing with itself the whole time rather than with reality. Build's starting question was whether that gap could be closed structurally — by making a gate's pass condition the existence of a real artefact rather than a claim about one, and by measuring the platform's own progress the same way, including when the honest number is worse than the one previously on record.
How it works, without the jargon
In practice, a project inside Build moves through a defined set of lifecycle states, and moving between them is validated centrally rather than left to whichever screen happens to be doing the moving. Requirements are recorded and linked forward through the design and work that is meant to satisfy them and the tests meant to verify them, so a chain that breaks — a requirement nothing tests, say — is reported as broken rather than quietly treated as complete.
A change to one part of a project — an architecture component, say — is traced through to the other things that depend on it, so that "nothing else depends on what you changed" is a computed answer rather than an assumption. Gates that require evidence or a recorded approval check for an actual artefact — a document, a decision, a file — rather than a form field asserting one exists. Everything that changes a project writes an audit record in the same transaction as the change itself, so the audit trail cannot end up describing a different set of events from what actually happened.
What building it taught me
The clearest lesson was how often a defect hid behind a test that looked correct. More than once the automated suite passed cleanly while the feature it was meant to cover did not work at all — because the test asserted something true about a fixture that was not true about the real system, or because a check that should have failed loudly instead returned an empty, confident answer that looked like success.
Several of the more serious problems only became visible by actually rendering a page, or actually sending many requests at once against a real deployment, rather than by reading code or running a unit test in isolation. That reordered my sense of what "tested" should mean here: a green suite is necessary and nowhere near sufficient, and some of the most important checks in this project are the ones that run against something closer to the real thing — a pre-production deployment, a restricted database role, concurrent load — rather than a fast, isolated fixture.
The other lesson was about scale: closing one gap in the requirements traceability made a different page too large to read reliably, which is its own kind of regression that a passing test suite does not notice.
Where it stands today
Build is in development, private, and not released. Its lifecycle engine, evidence and approval recording, requirements traceability, change-impact analysis and audit writing are implemented and have been checked against a real pre-production deployment, not just against unit tests, and 2,364 unit tests pass at the project's latest commit.
Against its own V1 specification, though, a large-scale review — each finding checked by a second, independent pass whose job was to try to disprove it — found 118 gaps that survived, 29 of them treated as blockers. Some of the platform's most serious defects, including one that could have let one organisation see another's data under a pooled database connection, have been found and fixed since that review, and the fixes are now checked as standing release gates.
The owner's standing instruction is that Build is not deployed to production until the V1 gates genuinely pass, and by the platform's own honest accounting, they do not yet.
Where it may go
Next: close the remaining items in the V1 gap register in the priority order the owner has set, working from the ones that block a gate outward. Then: get the full automated test suite — now well over a thousand end-to-end tests alone — running reliably inside its time budget as a matter of course rather than something that needs active shepherding. Later, if the V1 gates genuinely pass on their own evidence rather than on a description of them passing: deploy Build to production for the first time.
None of this is scheduled against a date; it is described here as the order the remaining work is intended to happen in, because that is what the project's own records commit to.
For developers: the tenant-isolation and concurrency defects, and how the gap register was produced
The platform's identity-scoping defect is worth describing in a little more detail because of how it hid. Under a pooled database connection, a mechanism intended to say "these queries act as this organisation" was set and cleared at the level of the connection rather than the individual unit of work, which is correct only when a connection never serves more than one caller — true of the development database used in most testing, and false the moment connections are shared under load. The fix moves that mechanism inside an explicit transaction boundary using a construct that is automatically discarded when the transaction ends, whichever way it ends, so a connection handed back to a pool never carries an identity from the request that used it last.
The concurrency defect that made a deployed service hang had a similar shape: a database connection was memoised at a scope wider than the individual request, on infrastructure where holding a connection open across requests is not the architecture's job — a separate pooling layer sits below it precisely so the application does not have to hold its own pool. The fix opens and closes a connection per unit of work, which would be poor practice against a bare, unpooled database and is the correct shape here, because the pooling problem is already solved one layer down.
The 118-item gap register was produced by a large parallel review: each finding was made by one independent pass, then handed to a second, independent pass whose task was specifically to try to refute it, with uncertain findings defaulting to refuted rather than counted. That asymmetry — a finding has to survive an attempt to disprove it, not merely be asserted — is deliberate, and is the same standard the platform tries to apply to the projects it governs.
A number of the platform's more serious defects were only found by running something against real infrastructure rather than by reading code or running a fast, isolated test — concurrent requests against a genuine deployment, a database role that cannot bypass access rules, an actual accessibility-tree walk over a rendered page at real size. Each of those is now a standing check rather than a one-off investigation, on the view that a defect found once by an unusual method will be found again by the same method if nothing keeps checking for it.