When an AI-built app is broken, someone will suggest starting over, and the suggestion always sounds clean: this time, with everything you learned, done right. Sometimes it is even correct. Usually it is not, and the difference is worth real money in both directions, so it deserves a real decision instead of a mood. Here is the framework we use, built on a strong default and three specific exceptions.
Quick answer: Rescue is the default: stabilize, secure, and test what exists. Rebuild only when the audit finds one of three things: a data model wrong at its core, a framework fighting the product’s actual shape, or security debt so pervasive that verifying fixes costs more than regenerating with guardrails. Price both paths before believing either.
Why is rescue the default?
Because the broken app contains paid-for knowledge that a rebuild throws away. Every edge case handled, every workflow adjustment, every small decision encoded across months of prompting: v2 must rediscover all of it, and rediscovery ships bugs of its own. There are also users, data, and integrations attached to what exists, and rescue keeps them attached. And there is the process truth from the technical debt guide: most broken means untested and unverified, which is curable in place. Rebuilding to escape a process problem imports the process into a fresh codebase and calls it progress.
What makes an app rescuable?
The common case, which is most of them: a standard stack (React, Node, Supabase or similar), data that is intact and correctly shaped even where the code around it is messy, breakage that is bounded (features fail, but the core transaction can be made to work), and problems whose names are already on the debt list: no tests, loose security rules, duplication, tangled patches. Every one of those has a known, priced fix. Ugly is rescuable. Untested is rescuable. Insecure is rescuable, urgently. None of them, at any volume, adds up to start over.
What are the true rebuild signals?
Three, and they share a property: they live below the code, where fixing means replacing anyway.
- The data model is wrong at the core: the entities themselves misrepresent the business in their nature rather than their naming, so every feature built on them inherits the lie, and migration would touch everything at once.
- The framework fights the product: the app’s architecture assumes a shape (static site, single user, no realtime) that the product has permanently outgrown, and the workarounds now cost more than the foundation.
- Security debt is pervasive rather than local: when trust in the codebase is so low that verifying every path costs more than regenerating the app inside guardrails from day one, with the old app as the perfect spec.
An audit exists to test for exactly these three, in writing, with evidence.
How do the costs compare?
Rescue: an audit at market rates of $500 to $1,000, then stabilization typically in the low to mid four figures, and the app keeps running throughout. Rebuild: a full custom build, which our web application cost guide prices honestly in the tens of thousands for anything substantial, plus the migration of users and data, plus the weeks of feature rediscovery, minus one real asset: v1 is now a complete, running specification, which genuinely does make v2 cheaper and better-aimed than a first build. That discount is real. It is also nowhere near the discount people imagine when the rebuild suggestion first sounds clean.
What does a rescue involve?
A rescue runs as a sequence: reproduce and stabilize the active breakage, close the security findings, add end-to-end tests on the flows that matter so fixed stays fixed, then pay down the debt that charges interest and stand up the production basics from the readiness checklist: monitoring, backups, a deploy pipeline. One to three weeks for a typical app, users undisturbed, and the endpoint is an app that is both working and changeable, which is the property the app lost in the first place.
How do you decide in one afternoon?
- Is the core data model an accurate picture of the business? (Look at the tables instead of the screens.)
- Can the app’s architecture serve the product you now know you are building?
- Is the breakage bounded and nameable, or is it everywhere you look?
- What did rescue and rebuild each cost when priced in writing, on your actual codebase?
- If rebuilding: what, specifically, prevents the new build from arriving at this same spot in six months?
Question five is the filter that catches most rebuild enthusiasm, because the honest answer is guardrails, and guardrails work on the existing app too. If you want the questions answered against your real code rather than in the abstract, that is the audit, and the report answers them with receipts.
Frequently asked questions
The developer says rebuild and the AI says it is fine. Who is right?
Neither, on authority alone. Ask the developer for the specific finding (data model, architecture, or pervasive security debt) in writing, and ask the AI nothing, since it has no visibility into its own blind spots. Evidence settles it; a second opinion on a rebuild verdict is always worth its small cost.
Can we rebuild with AI again, but properly?
Yes, and when a true rebuild signal exists, that is exactly the move: regenerate inside guardrails (tests, pipeline, rules file, review) with v1 as the specification. Same tools, different process, and the process was the problem.
Will users notice a rescue?
Ideally only as improvement. Rescue work happens behind the running app: fixes land through a pipeline, the interface stays familiar, and downtime is a planned maintenance window if it exists at all. Rebuilds are what users notice.
What about keeping the frontend and redoing the backend?
A legitimate middle path when the interface is loved and a rebuild signal lives in the data layer. It is still a serious project (the seam between old front and new back is where the effort goes), and it beats a full restart when it applies.
How long does each path take?
Rescue: one to three weeks to stable and tested for a typical app. Rebuild: a real build timeline, weeks to months, plus migration and a parallel-running period. The asymmetry is the point, and it is why rebuild needs a forcing finding rather than a feeling.
What happens if we do nothing?
The app continues to work until something ends the streak: a dependency breaks, a security scan finds the open door, or growth exposes the missing operations. Doing nothing is choosing to take the audit’s findings as surprises, on the app’s schedule instead of yours.