The feature was “ready to ship.” Four rounds of NO-GO followed.

Everyone agreed it was done

The feature was functionally complete. It had been built to spec, demoed, and tested end to end by the team that wrote it. Every path they tried worked. On a normal project this is the moment the release goes out.

Nothing in that exchange is dishonest. The team tested what they built, and what they built worked. The problem is that “we tested it and it works” answers a different question from “what happens when it doesn’t.”

Round 1: seven findings, two of them P0

An independent review — adversarial by design, with no stake in the release date — went looking specifically for the failure paths. It came back with seven findings and a NO-GO verdict. Two were P0, meaning real money was at risk the day this went live.

Neither of these was reachable through normal use. You get to them by killing the process at an inconvenient moment, or by delivering the same event twice — exactly what production does to you eventually, and never at a convenient hour.

Rounds 2, 3 and 4: the same word, new failures

Each round the findings were fixed and the feature was resubmitted. Each round the verdict came back NO-GO for a reason nobody had raised before. This is the part founders are never shown — not because it is hidden, but because it happens inside an engineering conversation nobody invites them to.

1. ROUND 2 · NO-GO

   Atomicity

   Multi-step money movement had to become all-or-nothing. Half-completed transfers are not an edge case; they are the default outcome of any interruption.

2. ROUND 3 · NO-GO

   Resumability

   A job that dies must be safe to run again. Without that guarantee, restarting a failed payout run risks paying twice — and “we’ll do it manually” is not a recovery plan at volume.

3. ROUND 4 · NO-GO

   Checkpoint durability

   Progress markers were being written in a way that did not survive an abrupt restart. The system believed it had resumed correctly. It had not.

Notice the shape: nothing here is about whether the feature works. All four rounds are about what the system does when reality interrupts it — and reality interrupts constantly.

Then staging found three more

After the fourth round the feature went to a staging environment carrying production-shaped data and production-shaped load. Three further bugs surfaced there that no simulation had produced.

• A timing interaction that only appeared when two operations landed within the same fraction of a second.
• A state combination that simulated data never generated, but real history did.
• A retry path that, in this specific sequence, could credit a payout twice — a free-money leak on day one of launch.

That third one is the whole argument for a staging environment in one line. It would not have been caught by more unit tests, a longer demo, or another round of code review. It needed the system to be run against reality before it was run against customers.

What shipping actually required

The test suite grew from 51 to 76 tests, and the additions were almost entirely about failure: kill the process here, deliver this event twice, restart mid-run, run the same job again. A zero-drift invariant was added on top — a continuous check that the money in the system reconciles exactly, with no tolerance band. Not “close enough.” Zero.

“The feature never got worse between round one and round four. What improved was how much we knew about it.”