Refactor or rebuild your AI-built app?

If your AI-built app works, has users and holds data you care about, refactor it: keep it and fix it in place, one area at a time. Rebuild only when the data model is wrong at its core, when nobody can safely change the code, or when the product itself has changed so much that little of the old app will survive. Even then, replace it piece by piece rather than in one big switch.

This guide is for founders who built an app with Lovable, Bolt, v0, Replit or another AI tool and now face a quote for a cleanup and a quote for a rewrite. It gives you a scorecard to decide between them, the signs that a rebuild is right, and a way to change the app without stopping it. Outside facts come from the pages listed under Sources, checked on 2 October 2026.

Should you refactor or rebuild an AI-built app?

Refactor by default. Refactoring changes how the code is built without changing what users see. On an AI-built app that work is often called vibe code cleanup. It keeps everything the app already does, including the small fixes nobody wrote down.

That last point is the strongest argument against a rewrite. In a 2000 essay, Joel Spolsky called Netscape's decision to rewrite its browser from scratch the single worst strategic mistake that any software company can make. His reason still holds: old code that looks messy often contains fixes for real problems found by real users. Martin Fowler makes a similar case. Replacing a serious IT system takes a long time, users cannot wait for new features, and it is hard to find out everything the old system does.

AI-built apps add a twist. Their code is newer and smaller than most legacy systems, so a rebuild looks cheap. But the product knowledge is just as hidden. Chat prompts are not a specification: they record what you asked for, not what the code does now. A rebuild has to rediscover every rule the prototype enforces, and the ones it misses ship as bugs.

How do you score your app?

This scorecard is our own guidance, not an industry standard. Score six areas from 0 to 2. Zero means broken or unknown, 1 means partly in place, 2 means solid and checked. Developers can fill most of it in during a short code audit; you can answer the last row yourself.

Add up the six scores. Then read them this way:

• 8 to 12: refactor. The foundations hold. Fix the weak rows first, then keep building.
• 4 to 7: refactor, and plan to replace one or two areas. Start with any weak row that puts users' data at risk, such as access rules or secrets.
• 0 to 3: look hard at a rebuild, but check the two rows that matter most before you decide: data model and roadmap fit.

The total is a guide, not a verdict. Weak tests, loose secrets and messy dependencies are all fixable in place. They are the normal technical debt of a fast prototype. A data model that is wrong at its core, or a roadmap that no longer fits the app, is different. Those two can justify a rebuild on their own.

When is rebuilding the right call?

Rebuild when fixing in place would cost more than replacing, and you can say exactly why. The common reasons:

• The data model is wrong at its core. For example, a single-user app that now has to serve teams, and the tables have no idea a team exists. Every feature touches it, so patching it means rewriting most of the app anyway.
• Nobody can safely change the code. It does not build outside the AI tool, there are no tests, and every change breaks something unrelated. If even small fixes are a gamble, a rewrite of the worst parts may be cheaper.
• The product has changed. You built a booking tool and are now selling a marketplace. When most of the old app would be thrown away anyway, keeping it saves little.
• The platform cannot do what you need. Some requirements, such as an offline mobile app or a data residency rule, may need a different stack. Check this against the requirement itself, not a hunch.

Notice what is not on the list: ugly code, inconsistent naming, a framework a new developer dislikes, or a large number of lint warnings. Those are reasons to refactor. A rebuild for taste alone resets your product to zero and gives competitors time.

Watch for one more trap. A team that proposes a rebuild should be able to list what the current app does, rule by rule, before they start. If they cannot, the rebuild will quietly drop rules the prototype enforced. Our guide to handing over an AI-built app to developers covers how to write those rules down.

How do you replace an app without stopping it?

Use the strangler fig pattern. Martin Fowler named it after a rainforest vine that grows on a host tree, roots in the ground and can outlive the tree. New code grows alongside the old app, takes over one area at a time, and the old part is removed once nothing depends on it. Microsoft's architecture guide describes the same idea: a layer in front of the app sends each request to the old or the new version, and the share sent to the new one grows with each step.

In plain words, for an AI-built app:

1. 01Put every change through a gateMake sure every change goes through version control, review and automated checks, so nothing reaches users unseen.
2. 02Pick the riskiest areaUsually sign-in and access rules, or payments. Fix or replace that area first, while the rest keeps running.
3. 03Freeze the debtRecord today's counts of type errors, lint problems and failing tests. Old debt is allowed; a count that goes up fails the build.
4. 04Move one area at a timeSend one area, such as a page, a form or a background job, to the new or cleaned code. Check it in production, and only then remove the old code.
5. 05Keep the data where it isChange the database through reviewed migrations, not a big move. Both old and new code must work against it during the change.
6. 06Stop when it is good enoughWhen the scorecard rows are at 2, stop replacing and start building features again.

Microsoft's guide also says when this pattern is overkill: a small system that is simple to replace whole. A tiny internal tool with no users may be quicker to rebuild whole. Once an app has paying users and data, that test is harder to pass.

Looph, customer-feedback software its founder shaped in Lovable, shows both outcomes in one product. The product the founder designed stayed. Underneath it, our engineers rebuilt the hosting, the database security and much more. At handover, type checking had never run and lint reported 19,849 problems, so a real one was invisible. Every gate now runs in CI against a recorded baseline, as in step 3: old debt is tolerated, new debt is refused. Passing tests went from 1,152 at handover to 10,387, and row-level security now covers all 172 public tables. The Looph case study has the details.

What do refactoring and rebuilding cost in time and money?

We will not quote a universal price, because nobody can do that honestly without seeing the app. What we can say is where each path spends money.

Time follows the scorecard. Each row below 2 is a piece of work, and the data model and access rows are the largest, because every feature touches them. Either way, measure progress by scorecard rows moving to 2, not by lines of code rewritten.

Before you sign either quote, ask three questions. Which scorecard rows will this fix, and how will I see that? Can the app keep taking users while you work? What happens to my data and my existing users on switch-over day?

What should you do next?

1. Fill in the scorecard yourself for the rows you can answer, especially roadmap fit.
2. Get the code into a repository your company owns, so any developer can check it.
3. Ask for an audit before any quote. A quote written without reading the code is a guess.
4. Fix the riskiest row first: any row that puts users' data at risk, such as access rules or secrets.
5. Rebuild only the areas the scorecard says are beyond repair, one at a time.

Starter is $2,999 a month paid annually, or $3,999 month to month; Growth is custom. See pricing. To see where your app stands first, take the free production-readiness check: 19 questions, a score out of 100 and your three biggest risks.

Sources

Each outside fact above comes from one of these pages, checked on 2 October 2026.

• Martin Fowler: Strangler Fig, 22 August 2024 (martinfowler.com/bliki/StranglerFigApplication.html).
• Microsoft Azure Architecture Center: Strangler Fig pattern, updated 29 May 2026 (learn.microsoft.com/azure/architecture/patterns/strangler-fig).
• Joel Spolsky: Things You Should Never Do, Part I, 6 April 2000 (joelonsoftware.com).
• Martin Fowler: definition of refactoring (refactoring.com).
• npm documentation: npm audit (docs.npmjs.com/cli/v11/commands/npm-audit).
• Supabase documentation: Row Level Security (supabase.com/docs/guides/database/postgres/row-level-security).
• Lovable documentation: GitHub integration (docs.lovable.dev/integrations/github).
• Case-study facts: our Looph case study, as published on this site.