The build case comes before the code.

Ask a team six months into a difficult build what the system is for, and you will usually get several confident, incompatible answers. The engineers describe an architecture. The founder describes a vision. The finance lead describes a cost. Nobody is wrong — and that is precisely the problem. The system has no single written definition against which any of them could be wrong.

We refuse to start a build without producing one. We call it the build case, and it is deliberately short: the commercial question the system answers, the number that question is worth, the architecture that answers it, the scope in writing, and the measures that will decide — after launch — whether it worked.

What the document actually prevents

The build case is not ceremony. Each of its parts exists to kill a specific, expensive failure mode before it can start running up costs.

• Scope drift — because scope is fixed in writing, changes become priced decisions instead of silent absorption.
• The demo trap — because success is defined as a measured commercial outcome, not a convincing walkthrough.
• Architecture by momentum — because the technical shape is argued against the commercial question, not inherited from whatever the team built last.
• The unfalsifiable project — because a system that cannot fail against written measures also cannot meaningfully succeed.

If we cannot say what the system earns, saves or makes possible, we do not build it.

Why ambiguity is cheapest at the start

Every project carries a fixed budget of ambiguity. You can spend it at the beginning, in a document, where a wrong assumption costs a paragraph — or at the end, in production, where the same assumption costs a rebuild. Writing the build case first is not caution; it is arbitrage. The questions are identical either way. Only the price changes.

This is also why both partners write it together — one holding the commercial argument, one holding the technical reality. A strategy written by people who will not build it drifts optimistic. An architecture written by people who do not own the commercial case drifts elaborate. The document is honest because its authors have to live with both halves.

The verdict can be 'do not build'

The most useful build case we can write is sometimes the one that kills the product. A thesis that concludes 'this idea does not survive its own arithmetic' costs a few weeks and saves a year of the house's life. Most of our theses die on paper — which is why the ones that ship deserve to. A product house that cannot say no to its own ideas is not disciplined, it is romantic.