When to rebuild instead of fix an AI-built app
The AI-built app is broken in ways that feel structural. The instinct that follows is to rebuild from scratch this time with better discipline. The instinct is sometimes right and usually wrong. Most apps that look unfixable are actually fixable for less effort than a rebuild would take. A smaller set genuinely benefits from rebuilding. Distinguishing them is the highest-leverage decision in any rescue case.
I want to walk through the four diagnostic axes that separate fixable apps from genuinely-rebuild-justifying ones, the threshold where rebuild becomes the right answer, and the honest framing of what rebuild actually costs versus what operators usually estimate it at.
The default answer leans toward fix because fix preserves the work the app already represents. Rebuild is the right answer only when the work to fix exceeds the work to rebuild plus the value of what's being thrown away.
Axis one: state clarity
Can you describe the current state of the app accurately?
If yes: you know what the code does, you understand the architecture, you can describe the data model. The state is clear. Fixes can target specific known points.
If no: the code is opaque, the architecture is unclear, the data model is partially understood. The state is fuzzy. Fixes have to start with state discovery, which is slow.
When state is clear, fix is usually the right answer because the fixes can be surgical. When state is fuzzy, the discovery work is significant; in some cases, the rebuild work is comparable to or less than the discovery-plus-fix work.
The honest test: can you, right now, write a one-paragraph description of what each major component of the app does and why? If yes, state is clear. If no, state is at least partially fuzzy.
Axis two: dependency integrity
Are the app's dependencies current, working, and trustworthy?
If yes: packages install cleanly, no version conflicts, no abandoned dependencies, no security advisories on critical paths. The dependency graph is solid.
If no: install fails, conflicts exist, dependencies are abandoned or insecure, the lockfile is out of sync with reality. The dependency graph is unstable.
Dependency problems are usually addressable through targeted upgrades and replacements. They become rebuild justification when the dependency graph is so degraded that the upgrade path is itself a major project. An app dependent on three abandoned libraries that all need replacement is a different cost than an app with one outdated dependency.
The threshold: if upgrading dependencies would require touching most of the codebase, the dependency work approaches the rebuild work. If upgrading dependencies is targeted to specific modules, fix is still cheaper.
Axis three: drift severity
How far has the codebase drifted from coherent architecture?
If lightly: most of the app follows one architectural pattern. A few inconsistencies exist but most of the code reads coherently. Drift is contained.
If severely: the app reflects several inconsistent architectural patterns. Different components use different conventions. The codebase reads like it was written by several teams with no coordination. Drift is pervasive.
Light drift is fix work: identify the drift points, restore consistency, document what was done. Severe drift can be fix work or rebuild work depending on how much of the codebase is affected. When most components are drifted, fixing each one approaches the cost of rebuilding fresh against a single consistent architecture.
The threshold: if you can identify a small set of drift points (say, fewer than 10 specific places), fix is usually cheaper. If drift is distributed across most of the codebase, rebuild becomes competitive.
The deeper exploration of this question is in fix the AI-generated app before you rebuild it, which covers the triage that distinguishes structural drift from other shapes of brokenness.
Axis four: business risk
What's at stake if the wrong path is chosen?
Low risk: the app serves internal users, low transaction volume, no critical dependencies. A wrong choice costs time but not customer outcomes.
High risk: the app serves external customers, handles money or sensitive data, has critical SLA expectations. A wrong choice can compound into customer-affecting problems while you're still working out the rescue.
High-risk situations favor rebuild even when fix would be technically possible, because rebuild produces a clean known-good baseline that's easier to operate than a patched system whose behavior under stress isn't fully understood. The rebuild cost is paid against the risk of patches not holding under real conditions.
Low-risk situations favor fix because the consequences of imperfect patches are bounded. Fix the issues that matter; document what's known to be imperfect; move on.
The honest test: if a patch doesn't hold and the app fails badly in the next month, what's the consequence? If the consequence is meaningful, lean toward rebuild even at higher cost. If the consequence is recoverable, fix is the default.
Reading the axes together
The four axes interact. A clean reading on one axis doesn't override a problematic reading on others, but the combination tells you which path the situation actually wants.
Fix territory. State is clear, dependencies are mostly healthy, drift is contained, business risk is bounded. Most patches will work. Fix is the right answer.
Rebuild territory. State is fuzzy, dependencies are degraded, drift is severe, business risk is high. The cumulative weight of these conditions makes patching expensive and uncertain. Rebuild becomes the right answer because it produces a known baseline rather than continuing to debug an unknown one.
Mixed territory. Some axes favor fix, others favor rebuild. This is where the decision is hardest and where outside diagnosis is most useful. The right path depends on which axes weigh most for the specific business.
What rebuild actually costs
Operators usually underestimate rebuild cost. The estimate they have in mind is "build the same thing again, but cleanly." The actual cost is higher because:
The original spec is partly in the existing code and partly in the original operator's head. Reconstructing it is real work.
Edge cases the original build addressed (often without documentation) need to be rediscovered.
Integration with existing systems (which the original build presumably worked through) needs to be re-established.
The new build needs the discipline that produces a different outcome than the original. Without the discipline, the rebuild will recreate the same problems.
Operational knowledge (deployment, monitoring, incident response) needs to be transferred or rebuilt.
A realistic rebuild is often 70-100% of the original build cost, sometimes more for complex apps. The "rebuild cleanly" framing usually undercounts the rediscovery work.
This matters because the fix-vs-rebuild calculation is comparing actual costs. If fix costs 30% of original build and rebuild costs 80%, fix is the right answer even when fix produces an imperfect result. If fix costs 60% and rebuild costs 80%, the calculation shifts.
When rebuild is genuinely the right answer
After the diagnostic, the cases where rebuild is correct usually share these properties:
The existing app's purpose has materially changed since it was built. The architecture serves the old purpose, not the new one.
The existing app's quality (in dimensions you care about: security, performance, accessibility, maintainability) is below the threshold the business now needs.
The existing app was built with assumptions that don't hold anymore. Each fix would essentially rewrite around those assumptions, eventually approaching rebuild work.
The team that's going to own the rebuilt version is fundamentally different from the team that built the original, with different skills, different conventions, different priorities.
The cost of operating the existing app, even fixed, exceeds the cost of operating a new one designed for current needs.
When at least two of these apply, rebuild is usually the right answer. When fewer than two apply, fix is usually right.
The honest service framing
This decision is hard because the operator usually has emotional investment in one direction or the other. Sometimes they want to rebuild because the existing app feels like a constant frustration. Sometimes they want to fix because rebuild feels like admitting failure.
Neither emotional pull produces the right answer reliably. The structured diagnostic produces a better answer than instinct. Running through the four axes deliberately, scoring each one honestly, and reading the combination produces a recommendation that's grounded in actual conditions rather than feelings about the app.
VibeKoded's role in this kind of decision is to run the diagnostic with you. The diagnostic doesn't have to be expensive; it's a structured conversation about the four axes plus a brief inspection of the codebase. The output is a recommendation with reasoning, plus a rough scope estimate for whichever path the recommendation suggests.
Operators who run this kind of diagnostic before choosing a path produce better outcomes than operators who pick fix or rebuild based on instinct. The diagnostic is cheap; the decision matters.
If you've got a broken AI-built app and want help running the fix-versus-rebuild diagnostic before you commit to a path, send the app description, the symptoms you're seeing, and what's at stake. VibeKoded can scope a rescue diagnostic, stabilization sprint, or rebuild plan. → Work with VibeKoded