Your tests pass. Would they catch a real bug?
Every month we plant 16 realistic bugs in your code, one at a time, and run your own tests against each. You get a score, every bug that slipped through, and the test that would have caught it.
Three steps. One number that means something.
- 01
Give us read access
One repo. Nothing is ever pushed to it: your tests run in a private copy.
- 02
We plant 16 realistic bugs
Chosen from failures we have seen in real AI-written code, fixed before anything runs, and planted one at a time against your own test suite.
- 03
You get the score and the fixes
Every bug that slipped through, with the file, the line and the test that would have caught it. Next month, new bugs, including in your new code.
Not a list of warnings. A list of tests to write.
Each miss says whether the code is never run by your tests or run without being checked, so you know which gaps are cheapest to close.
Your tests caught 4 of 16 realistic bugs.
Plan fixed before the run · sha256 f56e3b16…
An error inside an event handler was swallowed; the webhook answered 200, so Stripe would never retry.
Test to add: make a handler throw; expect a 500.Updating only a subscription's metadata wiped its org and user link.
Test to add: update metadata alone; assert both keep their values.One price. Cancel anytime.
The first month is the full setup run and report.
- 16 realistic bugs planted every month
- Your score, and its trend month over month
- Every miss with the file, the line and the test to add
- Last month's catches re-checked, so you know if a test was weakened
- Read access only; nothing is pushed to your repo
Repos up to about 100,000 lines. Full terms
Do you run our code?
Yes: your own test suite, in a private copy of your repository. Nothing touches your repo or your systems, and the copy is deleted within 30 days after you cancel.
Do you need write access?
No. Read access to one repo. Public repos need nothing at all.
What if our tests catch everything?
Then you have a score worth showing. Each month the bugs change: last month's catches come back as a regression check, and new ones go into the code you changed.
How is this different from mutation testing or a PR bot?
A PR bot reads one change at a time; mutation tools flip thousands of operators. We plant 16 bugs chosen from failures in real AI-written code, fixed before the run, and hand you the tests that close each gap.
Start with the repo you trust least.
The first month is a full run and report. If the repo is public, we can run a free preview first.