Test the paths that have never run
A billing error would have given top-tier customers a fifth of what they paid for. It was waiting in a feature nobody could test yet. How one round of hands-on review found it, and 30 other problems, before the first invoice.
The riskiest code in a product is often the code that has never run for real. On an AI sales-coaching product we built, billing was finished and deployed, but switched off: the client’s payment account and real prices were not set up yet. Nobody could buy anything, so nobody had.
What was hiding there
The billing system worked out which plan a customer had bought from a price code. When it did not recognise the code, it quietly fell back to the smallest plan. Until the client sets their real prices, no code would be recognised, so every subscriber would land on the wrong plan. A top-tier customer would have received a fifth of the usage they paid for.
Nothing looked broken. Every screen worked. The failure only appears the first time real money moves.
How we found it
We used every billing step the way a customer would, on features nobody could exercise yet. That round of hands-on review found and fixed 31 of 31 problems, this one included, before a single invoice went out.
Where to look in your own product
- Silent fallbacks. Any “if we do not recognise it, use the default” in code that touches money or permissions.
- Placeholders that will become real. Prices, plan names, keys and webhooks that are fake today and will be swapped on launch day.
- Paths behind a switch. Features that are deployed but disabled have passed no real use. Walk them anyway.
- The first time, not the hundredth. First sign-up, first invoice, first invitation: the flows that run once per customer are the ones nobody repeats in testing.
How we ship
We test the paths that have never run, not just the ones that look finished.
The examples in this article come from real engagements. Client details withheld; every figure comes from the client’s own data.
Read the case study →