We gave two different agents the power to block a release — on purpose.
One agent decides if it's built right. A different one decides if anyone will pay for it. Neither can call it 'done' alone. That split is the whole point.
The job I handed over
- Stop shipping things that work but don't earn. The org can build almost anything now; the risk isn't 'can we build it,' it's 'we built it and nobody bought it.'
What happened
- We'd been treating 'the build passes' as 'the product is done.' It isn't — and the receipts proved it: internal scores in the high 90s on a product with zero paying users.
- So we split oversight into two branches that don't report to each other. One owns 'is it built right' — production-ready, secure, tested. The other owns 'is it the right thing, and will it earn' — real customer, live way to pay, working unit economics — what each sale earns versus what it costs.
- Each branch gets the power to block a release on its own grounds, and neither can override the other. A product is only 'done' when both are green AND it's in-market and earning.
- The product side also gets a veto BEFORE the build starts — 'is this even worth building for a real customer' — so we kill bad bets before writing code, not after.
How I checked it
- The test of a real separation of powers: can one side quietly overrule the other? Here it can't — 'built right' and 'will it earn' are different questions, judged by different agents, and both are required.
- It closes the exact gap that produced the zero-users receipt: a green build with nobody accountable for whether the market wanted it.
- The check before building is the cheaper half — confirming demand before the build is far cheaper than discovering it after.
What it took from me
- Wrote the product-side rules down as rules that cannot be broken, with the same weight as the engineering rules: no build without a named customer and a painful, paid-for job; nothing ships to market without a live way to pay; every automated action stays visible and auditable.
- The cost is time: some builds now wait on a 'should we even build this' answer they didn't used to. That's the point — the slow 'no' is cheaper than the fast build nobody pays for.
What I took from it
- 'It works' and 'it sells' are different jobs, and letting one agent own both is how you end up with a beautiful product and an empty bank account. Build-ready is not launched. Done is in-market and earning — and it takes two independent yeses to get there.
Try this
- Name the two questions separately: is it built right, and will it earn. Notice if the same person answers both — that's the risk.
- Give each question a real owner and a real veto, and make 'done' require both approvals, not one.
- Add the cheap check at the start: before anyone builds, prove there's a named customer with a painful, paid-for job. Killing a bad idea on paper beats killing it after a build.
- Define 'launched' as in-market and earning — not 'deployed,' not 'it works in the demo.' If it isn't taking money, it isn't done.
Applies whenever the people who can build are also the people deciding what's worth building — which is most small teams, and every solo builder with an AI org.