Rescue or Rewrite? How to Decide for an App Built With AI Tools

When an app built with AI tools starts failing - bugs accumulating, performance degrading, security gaps showing up - the first question founders ask is whether to fix what exists or start over. The honest answer is that you cannot make that decision without looking at the codebase first. Founders who commit to a rewrite before reviewing the code often pay for a full rebuild that a targeted rescue would have avoided. Founders who try to rescue an app with structural problems spend that same money and end up with the same underlying issues, just buried one layer deeper.

Why This Decision Is Harder With AI-Built Code

Code generated by AI tools - Lovable, Bolt, Cursor, v0, and similar - tends to look clean at the surface level. The formatting is consistent, the naming is reasonable, the patterns are recognisable. What the surface does not show is whether the architecture is coherent, whether the data model supports what the product needs to do, whether the authentication is actually secure, or whether the codebase can be extended without unravelling what already exists.

This is the core difficulty: AI tools optimise for generating code that works for the immediate prompt. They do not have a view of the whole product, the growth trajectory, or the security requirements of a production system. An app that passes its own test cases and looks fine in a demo can still have authentication gaps, an incoherent data model, or patterns so tangled that any change risks breaking something else. The arXiv study Debt Behind the AI Boom analysed about 302,600 AI-authored commits from 6,299 GitHub repositories and found 484,366 distinct issues, of which 89.3% were code smells - structural patterns that accumulate into maintenance problems over time. It also found 22.7% of the tracked issues were still present in the latest revision of the repositories. Code smells are not bugs, but they determine whether a codebase can absorb change gracefully or whether every change costs twice what it should.

When we review an AI-built app before making a rescue or rewrite recommendation, we look at the signals below. They are not a formula - a codebase with two rescue signals and one rewrite signal does not automatically become a rescue - but they frame the analysis in a way that is consistent and explicable.

Signals That Point Toward Rescue

Rescue is viable when the problems are real but isolated. The codebase may have security gaps, missing error handling, slow queries, or hardcoded values - but these problems exist in specific places, not in the architecture itself.

The data model makes sense for the product. The tables, relationships, and naming reflect how the product actually works. A developer can read the schema and understand the business without a long explanation.
The authentication is the right tool, just misconfigured. A Supabase or Firebase auth setup with RLS disabled or a service role key in the frontend is a serious problem, but it is a fixable configuration issue - not a sign that the auth approach is fundamentally wrong.
The core user flows work, and the failure patterns are consistent. When the same class of bug appears repeatedly - missing null checks, unhandled promise rejections, or a specific query that times out - those are fixable patterns, not structural failure.
The codebase is under 20,000 lines of product code. Smaller codebases are cheaper to audit, easier to fix surgically, and faster to test after remediation.
The product is live with real users. Users who depend on the product create a constraint that favours rescue: a rewrite requires a migration plan for their data and a feature freeze while the new version catches up.

Signals That Point Toward Rewrite

Rewrite becomes the better option when the problems are architectural rather than surface-level. Fixing the surface when the structure is broken produces a better-looking version of the same problem.

The data model does not match the product. If the database structure was designed for the first version of the product and has been contorted to fit everything that came after, querying it requires workarounds that will never get cleaner.
There is no coherent access control model. If the app controls who can see what through a mix of frontend conditionals, partial backend checks, and database-level policies that conflict with each other, "fixing" one layer leaves the others broken.
Every change breaks something unrelated. If the developer (human or AI) cannot modify one part of the app without causing regressions elsewhere, the coupling between components is too tight to rescue incrementally.
The app was built on a platform that cannot support the product's next stage. An app that started as a Lovable prototype connected to Supabase, then had features bolt-connected via Zapier and Make, then had a custom backend added to fill gaps, may have reached the point where the integration surface is the problem - not any individual component.
The security issues are in the architecture, not the configuration. If the app design requires sending user data through the client that should never leave the server, that cannot be fixed without redesigning the data flow.

The Questions a Review Needs to Answer

A decision to rescue or rewrite should be based on a review of the codebase, not on how the app feels to use. When we do a rescue and launch review, the questions we are answering are:

Can we trace every authenticated action back to a specific user, and does the backend enforce that boundary? If the answer is no, the access control model needs to be rebuilt regardless of whether everything else is rescued.
Does the schema support the product's current feature set without workarounds? If three of the app's most important features require joining on fields that should be in the same table, the data model is working against the product.
What does the change history look like? If every AI-generated change looks like a fresh rewrite of the affected file rather than a targeted edit, the codebase has the shape of an AI-maintained project - and AI-maintained projects accumulate inconsistency over time in ways that are expensive to untangle.
What is the test coverage on the paths that matter most? Rescue is less risky when there are existing tests that confirm the core flows still work after a change. A codebase with no tests requires a higher confidence in the fix because there is no automated check that a rescue did not introduce a regression.

The Cost of Getting the Decision Wrong

Choosing rewrite when rescue was viable means paying for a full rebuild, managing a feature freeze, migrating user data, and rebuilding trust with users who experienced a period of instability. A common mistake is this one: founders who have lost confidence in the codebase assume a rewrite is the only option without testing that assumption against what the codebase actually contains.

Choosing rescue when rewrite was needed means paying a developer to work around an architectural problem that does not go away. This tends to be more expensive in the long run - not because of the developer's hourly rate, but because every feature takes longer than it should, every bug fix introduces uncertainty, and the moment you need to scale or add a significant feature, the work you paid for rescue has to be redone anyway.

The post How to Fix an App Built With AI Tools covers the specific failure patterns that appear most often in AI-built codebases - authentication gaps, database query problems, API key exposure - and how a focused rescue addresses each one. The post When You Outgrow AI Builders addresses the scenario where the platform itself, not just the code, is the constraint. The post What It Costs to Finish a Half-Built App gives realistic cost ranges for both paths.

Starting With a Review Rather Than a Decision

The founders who spend the least on this decision are the ones who start with a review rather than a conclusion. A targeted code review of an AI-built app is far quicker and cheaper than a rebuild, and produces a clear picture of the architectural signals, the security exposure, and a realistic estimate of what rescue would cost relative to what a rewrite would cost. That review changes the conversation: instead of "should we rescue or rewrite?" the question becomes "here is what rescue costs, here is what rewrite costs, and here is what each buys you."

To start that review, get a rescue and launch assessment of your app. If you want to run an automated scan of your repository first to see what class of issues are present before a full review, the free code review covers the security and dependency layer in minutes. Either way, the decision is easier after you have seen what is actually there.

Common questions

Should I rescue or rewrite my AI-built app?

You cannot decide without reviewing the codebase. Rescue fits isolated problems such as misconfigured auth or slow queries. Rewrite fits architectural ones, such as a data model that no longer matches the product or no coherent access control model.

What does it cost to choose wrong between rescue and rewrite?

Rewriting when rescue was viable means paying for a full rebuild, a feature freeze and user data migration. Rescuing when a rewrite was needed means working around an architectural problem that does not go away, so every feature takes longer and the work may be redone.

How do I find out whether my AI-built app needs a rewrite?

Start with a review rather than a conclusion. A targeted code review is far quicker and cheaper than a rebuild and gives a realistic estimate of rescue versus rewrite. Zovintra offers a rescue and launch assessment, and a free automated scan covers the security and dependency layer first.