Rescue or rebuild? How to decide for an AI-built app
Most launch problems sit around the code, not in it. A quick test for when to fix your AI-built app and when to start over.
When an AI-built app starts breaking under real users, the tempting move is to throw it away and start over, either with a new prompt or with a developer. Usually that's the expensive choice. Here's how I decide.
Rescue when the problems are around the app, not in it
Most launch problems sit in the layer around the code, not in the product logic:
- Database access: RLS off, weak policies, missing grants
- Secrets in the frontend
- Deploys that work in preview but not production
- No backups, no monitoring, no staging
- A few slow queries or an unindexed table
These are fixable in days, and fixing them doesn't touch the screens your users already like. If this list describes your app, rescue it.
Consider a rebuild when the core is wrong
- The data model can't represent what the product does, and every new feature fights it.
- The same logic is copy-pasted across dozens of components and each copy has drifted.
- No one, including the builder, can change one screen without breaking two others.
- The app needs things the stack can't do well, like heavy background jobs or real-time at scale.
Even then, a rebuild is rarely all or nothing. Keeping the UI and replacing the data layer is often the best of both.
A quick test
Answer these honestly:
- Do users like what the app does today?
- Can you describe your data in a few tables without exceptions everywhere?
- Are most bugs about access, deploys or reliability rather than wrong behavior?
Three yeses: rescue. Two: rescue, with one area rebuilt. One or none: talk to someone before you spend money in either direction.
What I do
The Launch Risk Diagnostic ends with a fixed quote. If rescuing would cost more than a rebuild, I'll say so in the report, before you pay for anything else.