Should you rebuild an AI-built app from scratch?

Not as a first step. Have the code reviewed first. Martin Fowler writes that plans to replace a serious system with a new one doing exactly the same thing "go down in flames most of the time," because users still need changes during the rebuild and the existing behavior is harder to specify than it looks. A review shows which parts are worth keeping.

How do you decide whether to fix or rebuild an AI-built app?

Look at six signals: whether security problems are confined or built into the design, whether the data model fits the business, whether the stack is mainstream, whether tests exist, how much of the app works, and whether you can export and own the code. Many apps point toward fixing on some and rebuilding on others, which suggests replacing parts one at a time.

Can security problems in an AI-built app be fixed without a rewrite?

The confined ones can: a leaked key, tables without row-level security, a server function without an ownership check. Design-level problems are different. OWASP states that "An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks." Those call for replacing the affected layer, not necessarily the whole app.

What makes a data model a reason to rebuild?

A data model that doesn't match how the business works, stores the same information in several places, or packs important data into unvalidated text or JSON fields makes every new feature harder. If it mostly fits, migrations can correct it. If it doesn't fit at all, the layers that depend on it may need rebuilding, and the amount of real data decides how costly that is.

Does an app without tests need to be rebuilt?

No. A developer can add tests around the most important flows, such as sign-in, permissions and payments, before changing them. A rebuild needs tests too, so missing tests raise the cost of both options without deciding between them.

What is the strangler fig pattern?

A way to replace software gradually. New code is built alongside the existing app, and features move into it one at a time while the app keeps running, until the old code can be retired. Martin Fowler named it after strangler fig vines, which start on a host tree and grow until they are self-supporting.

When does starting over make more sense than fixing?

When the app is small enough that replacing it is simple, when the code can't be exported, or when the design or data model is wrong throughout and there is little real data to move. Microsoft's guidance on the strangler fig pattern notes that gradual replacement may not suit a small system that is simple to replace.

Will rebuilding with AI tools avoid the original problems?

Not on its own. In a study of AI-generated code in GitHub projects, published in ACM Transactions on Software Engineering and Methodology, researchers found security weaknesses in 29.5% of Python and 24.2% of JavaScript snippets. In a user study at ACM CCS 2023, people using an AI assistant wrote less secure code and were more likely to believe it was secure. A rebuild needs the same review as the original.

What does a developer's assessment of an AI-built app include?

Getting the code running from the repository, a security first pass, a review of the data model and code structure, a feature-by-feature inventory with the owner, and a list of platform dependencies. The result is a written summary saying, for each part of the app, whether to keep, fix or replace it, in what order, and why.

Can you keep using AI tools after deciding to fix or rebuild?

Yes. Fixing, replacing parts and rebuilding can all use AI assistance. The change is the process around it: version control, human review of each change, and tests that catch regressions before users do.

Hands in a dark grey work shirt use a hex key to fit a new chainring to a cobalt blue bicycle frame on a repair stand, with the worn chainring lying on the workbench below

Fix or Rebuild an AI-Built App? How to Tell Which You Need

October 4, 2026 · 16 min read

An app built with Lovable, Bolt, Replit, v0, ChatGPT or Claude can reach the point where every fix seems to break something else. Starting over begins to look tempting: the first version came together in days, so a cleaner second version should be quick too. Sometimes that is the right call. Other times, keeping what works and fixing or replacing the parts that don’t gets there sooner and with less risk. Telling the two situations apart takes a look at the code.

This guide covers how to tell the difference: what each option involves, the signals that point toward fixing or rebuilding, the middle path of replacing one part at a time, and what a developer’s assessment looks like. It expands the “Should you fix an AI-built app or start over?” section of You Built It With AI. Here’s How a Developer Takes It Over, which covers the whole handoff.

Fixing vs. rebuilding an AI-built app: key facts

Question	Answer
Should you rebuild an AI-built app from scratch?	Not as a first step. Have the code reviewed first. Martin Fowler writes that plans to replace a serious system with a new one doing exactly the same thing “go down in flames most of the time.”
What decides between fixing and rebuilding?	Whether security problems are confined or run through the whole app, whether the data model fits the business, whether the stack is mainstream, whether tests exist, how much of the app works, and whether you can export and own the code.
Can a design flaw be fixed with better code?	Not by itself. OWASP states that “An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks.”
Is there an option between fixing and rebuilding?	Yes. Replace the weakest parts one at a time while the rest of the app keeps running, an approach known as the strangler fig pattern.
When does starting over make sense?	When the app is small enough that replacing it is simple, when the code can’t be exported, or when the design or data model is wrong throughout and there is little real data to move.
Will rebuilding with AI avoid the same problems?	Not on its own. Research has found security weaknesses in code from several AI tools, and people using AI assistants tend to overrate their code’s security, so a rebuild needs the same review as the original.
What does a developer’s assessment produce?	A part-by-part view of the app: what to keep, what to fix, what to replace, in what order, and why.

What do fixing and rebuilding an app involve?

The choice isn’t all or nothing. There are three broad options, and a single project can use more than one of them.

Fix in place. Keep the existing code and improve it. That includes correcting bugs and security problems, and refactoring, which Martin Fowler’s refactoring site defines as “a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” The app keeps running throughout.
Replace parts. Keep the app running while specific parts, such as the data access layer, the sign-in flow or the payment handling, are rewritten one at a time.
Start over. Build a new app alongside the old one, then switch users and data across once it is ready.

The rest of this guide is about deciding which mix fits your app.

Why does starting over look easier than it is?

A rebuild seems simple to describe: build the same app again, properly this time. Fowler, writing about legacy systems in his Strangler Fig article, says that “we’ve seen this simple-sounding plan go down in flames most of the time.” Two of his reasons apply to a small AI-built app too: users still need fixes and new features while the replacement is being built, and the details of what the existing app actually does are harder to pin down than they appear.

Ian Cartwright, Rob Horn and James Lewis call the goal of rebuilding exactly what exists today the “feature parity trap”. They write that people “greatly underestimate the effort required,” and that “even just defining the ‘as is’ scope can be a huge effort.” An AI-built app has its own version of this problem. Its behavior was shaped by a long series of prompts and corrections, and many of the small decisions inside it, such as how a form handles a blank field or what happens when a payment fails, were never written down.

A rebuild done with AI tools again doesn’t avoid the review step. In a user study published at ACM CCS 2023, Do Users Write More Insecure Code with AI Assistants?, participants who had an AI assistant “wrote significantly less secure code than those without access” and “were more likely to believe they wrote secure code.” A second version can look cleaner and still repeat the first version’s problems.

Rebuilding can still be the right answer, but the case for it should come from what a review finds rather than from frustration with the current version.

What signals point toward fixing or rebuilding?

Six questions cover the main signals. No single answer settles it; the pattern across all six does.

Are the security problems confined or everywhere?

Security weaknesses turn up often in AI-generated code, and many of them can be fixed where they are. In a study of AI-generated code found in real GitHub projects, published in ACM Transactions on Software Engineering and Methodology, Fu et al. found security weaknesses in 29.5% of the Python snippets and 24.2% of the JavaScript snippets they analyzed. When the researchers gave Copilot Chat the warnings from static analysis tools, “up to 55.5% of the security issues can be fixed.” Weaknesses like the ones they list, such as cross-site scripting (CWE-79), sit in specific lines of code that can be found and corrected.

The distinction that matters is the one OWASP draws in its Insecure Design category, between flaws in the code and flaws in the design. OWASP notes that the two “have different root causes, take place at different times in the development process, and have different remediations.”

Confined problems point toward fixing. A leaked key that can be rotated, a few database tables without row-level security, a server function that skips an ownership check, a webhook that doesn’t verify its signature. Each has a known fix in a known place. AI-Built App Security Checklist: What a Developer Checks First covers these one by one.
Problems built into the design point toward replacing that layer. An app whose browser code talks to the database with a secret key, where every permission check lives in the interface and there is no server code to move them to. OWASP’s Broken Access Control category states that “Access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata.” If the app has nowhere for that code to live, it needs a new layer rather than a patch.

Even a design-level problem may call for replacing one layer rather than the whole app, with the screens and working features kept on top.

Does the data model fit how the business works?

The data model is the set of tables in the database and the way they relate to each other. It is also one of the harder parts of an app to change later, because real records depend on it and many features read from it.

Signs of a sound data model:

Each kind of thing the business deals with (customers, orders, bookings, invoices) has its own table.
Related tables are linked with foreign keys. PostgreSQL’s documentation on constraints explains that a foreign key “maintains the referential integrity between two related tables,” so an order can’t point to a customer who doesn’t exist.
Columns hold one kind of value each, with types that match (dates as dates, amounts as numbers).

Signs of trouble:

The same information is stored in several places and drifts out of sync.
Important data is packed into free-form text or JSON fields that nothing validates.
New features need workarounds because the tables don’t match how the business operates.

A data model that mostly fits can be corrected with migrations, the versioned scripts that change a database’s structure step by step. One that doesn’t fit at all is one of the strongest arguments for rebuilding the layers that depend on it, and the amount of real data already stored in it decides how costly that will be.

Is the stack mainstream and maintainable?

The framework and database an app is built on decide how easy it is to find developers, documentation and support for it later. The tools covered here mostly generate code on widely used foundations. v0 builds with Next.js and React, and Lovable apps use React with either TanStack Start or Vite. In the 2025 Stack Overflow Developer Survey, 44.7% of all respondents said they had done extensive development work with React in the past year and 20.8% with Next.js, while PostgreSQL, the database underneath Supabase, was the most used database at 55.6%.

A mainstream stack points toward fixing. Warning signs are narrower:

Services only the builder provides. Some features exist only inside a platform and have no direct equivalent elsewhere. Replit’s authentication documentation, for example, states that “The only way to implement Replit Auth is by using Agent.” Features like these need replacing when the app moves, which is a part-by-part job rather than a reason to start over.
A tangle of overlapping libraries. Two packages doing the same job, or dependencies nobody can explain. These are cleaned up during a fix.
A stack that doesn’t suit the product. For example, an app that needs a PHP or Python backend for an existing system, built in a tool whose supported technologies page says “Bolt focuses on JavaScript-based web technologies.” This is one of the few stack issues that can justify a rebuild.

Are there tests, and do they mean anything?

Automated tests are what make fixing safe. They show when a change breaks something that used to work, which is the problem owners describe when every AI fix causes a new bug.

An app without tests can still be a good candidate for fixing. A developer writes tests around the parts that matter most, such as sign-in, permissions and payments, before changing them. Supabase’s row-level security guide, for instance, recommends SQL tests that check which roles can and can’t read or change each table.

What counts is what the tests cover, not a percentage. Fowler’s note on test coverage describes coverage as “a useful tool for finding untested parts of a codebase” but “of little use as a numeric statement of how good your tests are.” Tests generated in bulk to raise a number, or tests that pass without checking anything meaningful, add little.

A lack of tests doesn’t decide between fixing and rebuilding, because a rebuild needs tests too. It does affect the cost of both.

How much of the app works?

List every feature and mark each one: works, works with known bugs, or broken. The list shows whether the problems that cause the most frustration are spread across the app or concentrated in a few areas.

Most features work, with problems in specific areas: fix, and replace the problem areas if needed.
The core workflow works, but the parts around it don’t: keep the core and rebuild the surrounding features.
Little works reliably, and each fix breaks something else: this points toward rebuilding, especially if the data model is also weak.

Code quality matters most where the app will change. Fowler’s technical debt article puts it this way: “crufty but stable areas of code can be left alone,” while areas that change often deserve close attention. Messy code in a settings page nobody touches costs little. Messy code in the checkout that gets changed every week costs more each time.

Can you export the code and own it?

None of the fixing options work if a developer can’t get to the code. Lovable, Bolt, Replit and v0 all document a way to connect a project to a GitHub repository, and Lovable’s ownership guide states: “Your apps, code, and content you create with Lovable are yours, subject to third-party rights such as open-source licenses.” Exporting From Lovable, Bolt, Replit or v0: What You Get covers each tool’s export and what stays behind on the platform.

Exporting can still be blocked. Replit’s guide to copying projects notes that workspace admins can turn on “Ban source code export.” If the code can’t be exported at all, for any reason, rebuilding is the only option. Microsoft’s description of the Strangler Fig pattern lists not having access to the existing system’s source code as one of the cases where gradual replacement may not be suitable.

Fix or rebuild an AI-built app: decision table

Signal	Points toward fixing	Points toward rebuilding (part or all)
Security problems	Confined to specific keys, tables, functions or webhooks	Built into the design, such as all access control in the browser with no server code
Data model	Matches the business, with linked tables and sensible types	Doesn’t match the business; data duplicated or packed into unvalidated fields
Stack	Mainstream framework and database, builds from the repository	Depends on platform-only services throughout, or can’t support what the product needs
Tests	Some exist for key flows, or can be added before changes	None, and the behavior is too unclear to test (raises the cost of either option)
How much works	Most features work; problems are in a few areas	Little works reliably; fixes keep breaking other features
Export and ownership	Code is in a repository you control	Code can’t be exported or the terms are unclear
Size	Large enough that rebuilding would take a long time	Small enough that replacing it is simple
Real data	Real users and records already exist	Little or no real data yet

Many apps land on the fixing side for some rows and the rebuilding side for others. A mixed result like that points to the middle path.

The strangler fig pattern: replacing one part at a time

Fowler named this approach after the strangler figs he saw in Queensland’s rain forests. These vines start in a nook of a host tree and draw on it until they have roots and sunlight of their own, and the host may eventually die. In his Strangler Fig article, he describes the software version as a gradual process that “begins with small additions, often new features, that are built on top of, yet separate to the legacy code base,” after which behavior moves from the old code into the new code piece by piece.

Microsoft’s architecture guide explains the mechanics. A layer in front of the app, which it calls a façade, sends each request either to the old code or to the new code. As more features move across, more requests go to the new code, until the old system can be retired. Microsoft adds that customers “continue to use the same interface and are unaware that a migration is in progress.”

For an AI-built app, one order that follows the risk:

Secure what is there first. Rotate exposed keys and close open database access in the current app. These fixes can’t wait for a replacement.
Replace the data and access layer. Move database queries and permission checks into server code with proper tests, while the existing screens keep working on top of it.
Rebuild the worst features one at a time. Pick the features that break most often or matter most to revenue, such as checkout, and replace each behind the same interface.
Build new features in the new structure. Anything new goes into the improved code from the start rather than into the old patterns.
Retire what has been replaced. Delete old code once nothing depends on it, so the app doesn’t carry two versions of the same feature.

This approach has costs. Fowler acknowledges that it needs “transitional architecture” that will be thrown away when the work is finished, and argues that “the reduced risk and earlier value from the gradual approach outweigh its costs.” Microsoft’s guide also lists cases where it may not be suitable, including “You migrate a small system and replacing the whole system is simple.” A small prototype with a handful of screens and no real users may be quicker to rebuild outright, using the original as a working specification.

What does a developer’s assessment look like?

Before recommending a fix or a rebuild, a developer reviews the app as it is. A typical assessment covers:

Getting the code running. Clone the repository, install it and run it on a clean machine using only what is written down. Anything that only works inside the builder is noted.
A security first pass. Secrets, database access rules, server-side authorization, dependencies, input validation and error handling, in the order described in the security checklist.
The data model. Read the tables, relationships and migrations, and compare them with how the business works, ideally with the owner explaining the workflow.
The structure of the code. Look for logic copied across many files, permissions checked in the interface only, and the dependencies each part relies on.
A feature inventory. Walk through every feature with the owner and mark what works, what is buggy and what is missing.
Platform dependencies. List every service the app uses, who controls each account, and which ones would need replacing outside the builder.

The result should be a written summary, not a single verdict. For each part of the app, it says whether to keep it, fix it or replace it, in what order, and why. Urgent security fixes come first regardless of the longer-term plan.

What an owner can bring to make the assessment faster and cheaper: repository access, a list of services and logins, a short description of what works and what doesn’t, and the prompts or project instructions given to the AI tool. The handoff guide’s preparation list covers these in more detail.

Can you keep using AI tools either way?

Yes. Fixing, replacing parts and rebuilding can all be done with AI assistance. What changes is the process around the tools: changes go through version control, a person reviews them, and tests catch regressions before users do. Those checks catch a change that breaks another feature before users see it, whichever option you choose.

When to bring in a developer

The right time for an assessment is before committing to either path, and especially before real users, personal data or payments go live in an app you are unsure about.

If you’d like an assessment, the process and pricing are published, and you can get in touch to talk through what you’ve built.