Rebuild an AI-generated app only when its foundations make every future change slow or risky: a data model that cannot represent your business, security that cannot be enforced where it needs to be, or code nobody can change without breaking something else. If the core workflows work and the problems are fixable, refactor and harden it instead. Between those two sits the option most founders overlook: replacing parts of the app while keeping the rest running.
Key takeaways
- Fixing is the default. A rebuild repeats work, delays launch and still needs a data migration.
- Judge the foundations, not the surface. Messy components are cheap to fix; a wrong data model is not.
- Partial rewrites exist. Rebuilding the backend behind a working frontend is often the best of both.
- Capture behaviour before you rebuild. Tests against the old app protect features nobody remembered.
The four options, not two
“Rebuild or fix?” sounds binary, but there are really four paths, and the right one often differs between the frontend and the backend of the same app.
| Option | What it means | Best when |
|---|---|---|
| Harden | Keep the code, fix security, config, tests and deployment | Foundations are sound, gaps are operational |
| Refactor | Restructure code without changing behaviour | Logic is right but tangled or duplicated |
| Partial rewrite | Replace one layer or module, keep the rest | One part is broken, others are fine |
| Full rebuild | New codebase, old app as the specification | Foundations block the product you need |
Signs you should fix, not rebuild
- Users can complete the core workflow and the logic behind it is broadly correct.
- The data model maps to real concepts in your business, even if it needs constraints and tidying.
- Access rules can be enforced in the database or a backend layer without restructuring everything.
- The code is messy in places but readable, and a developer can explain what most of it does.
- Problems cluster around security settings, missing tests and deployment, which are fixable in place.
This describes most AI-built MVPs we assess. The generated frontend in particular is often worth keeping: its structure may need cleaning, but it already encodes many product decisions that users have validated.
Signs a rebuild, or a partial rebuild, is justified
- The data model is wrong at its core. For example, a product that needs teams and permissions stores everything per user with no notion of an organisation, or key business data lives in unstructured JSON that needs reporting and constraints.
- Security cannot be enforced where it must be. All logic lives in the browser and talks directly to a database that has no reliable way to express your access rules.
- Changes routinely break unrelated features because the same logic is duplicated across many files with small differences.
- The platform blocks a requirement you cannot drop, such as data residency, an integration, or self-hosting.
- Nobody can run it outside the builder and exporting it produces something that does not build.
A simple way to score your app
Rate each area from 1 (blocks progress) to 3 (fine or easily fixed). The pattern tells you more than the total.
| Area | Question to ask | Weight |
|---|---|---|
| Data model | Does it represent the business, including where it will be in a year? | High |
| Authorisation | Can access rules be enforced on the server or in the database? | High |
| Changeability | Can a developer change one feature without breaking others? | High |
| Test coverage | Can we tell automatically when something breaks? | Medium |
| Code clarity | Can someone new explain how the main flows work? | Medium |
| Frontend quality | Are the screens and components reusable and consistent? | Low to medium |
| Hosting and config | Can it be built and deployed from a repository you own? | Low (fixable) |
Low scores only in the bottom half of the table point to hardening. Low scores in the top three rows, especially the data model, point to rebuilding at least the backend. Martin Fowler’s description of technical debt is a helpful lens: the question is not whether the code is ugly, but how much extra effort every future change will cost because of it.
The costs founders forget
A rebuild quote usually covers writing the new code. The real cost also includes:
- Feature parity. The new app must do everything the old one did before users can switch, including small behaviours nobody wrote down.
- Data migration. Existing users, records and files must move across, mapped to the new model, verified and rehearsed.
- Opportunity cost. Weeks spent rebuilding are weeks not spent on what customers are asking for.
- Running two systems. During a migration, both may need hosting, monitoring and support.
Fixing has costs too, mainly that some debt remains and slows later work. That is acceptable when the debt is in parts of the app that rarely change.
The middle path: replace it in pieces
The Strangler Fig approach, named by Martin Fowler, builds new functionality alongside the old system and gradually moves behaviour across until the old parts can be retired. For an AI-built app, this often looks like keeping the frontend, introducing a proper backend API with authorisation and validation, then moving screens one at a time from talking to the database directly to talking to the new API.
The advantages are practical: users keep working throughout, each step can be tested and rolled back, and you stop at whatever point the remaining old code is good enough.
If you do rebuild, do it safely
- Document current behaviour, ideally as automated end-to-end tests that pass against the old app.
- Design the data model first, including tenancy and constraints, and plan the migration from day one.
- Rebuild in thin vertical slices, each one usable, rather than layer by layer.
- Rehearse the data migration on a copy of production before the real switch.
- Keep the old app available, read-only if necessary, until the new one has proved itself.
Whichever path you choose, the end goal is the same production foundation we describe in our roadmap from AI prototype to production-ready SaaS. If the data model is the sticking point, read why your SaaS needs a proper database before it scales.