Rescue or Rebuild? How to Decide on an AI-Built App

You have run the diagnostic, or someone has run it for you, and the list is longer than you hoped. Now comes the expensive question: do you repair what you have, or throw it away and build it properly? Get this wrong in one direction and you spend two weeks patching something that was never going to hold. Get it wrong in the other and you burn three months rebuilding a product that only needed a fortnight of attention.

There is a rule that settles it, and it is not about how much of the code an AI wrote. It is about the database.

The rule: let the data model decide

Everything in an application is replaceable except its data model. Interfaces get redesigned, endpoints get rewritten, the framework gets swapped, and none of that touches the records you already hold. But if the shape of the data is wrong, every layer above it inherits the mistake, and fixing it means migrating live customer data while the product is running.

So the question is not "how bad is the code?" It is "is the schema right?"

If your schema is broadly correct and the problems sit in authorization, secrets handling, error paths and missing tests, those are additive fixes. You can do them one at a time, ship each one, and never take the product down. That is a rescue, and it is dramatically cheaper than a rebuild.

If the schema itself is wrong, entities that should be separate crammed into one table, no relationships where relationships belong, the same fact duplicated across three places so it can silently disagree with itself, then fixing it means migrating everything above it anyway. At that point rebuilding those layers is usually cheaper than repairing them, because you are rewriting them either way.

How to check your schema in ten minutes

You do not need to be a database expert. Open your schema and answer five questions honestly.

1. Is the same fact stored in more than one place? If a customer's email lives on the users table and again on the orders table, they can disagree, and one day they will. Duplication that exists for speed is fine when it is deliberate and one-directional. Duplication that exists because the model was never designed is a defect.
2. Do relationships exist, or are they implied? Look for actual foreign keys. AI tools frequently generate tables that reference each other by an id with nothing enforcing it, which works perfectly until the first orphaned record and then quietly corrupts your reporting.
3. Is anything important stored as unstructured text or JSON? A status field holding free text rather than a constrained set of values means every query that filters on it is guessing. One JSON blob for flexible metadata is reasonable; core business fields inside a JSON column are not.
4. Can you answer your three most important business questions with a query? Monthly revenue by customer, active users last week, orders stuck in a given state. If any of those needs application code to work out because the data cannot express it, the model is missing something structural.
5. Does deleting a record leave debris? If removing a customer leaves their orders, sessions and files pointing at nothing, you have no cascade rules, and that is both a correctness problem and, under most privacy regimes, a compliance one.

Zero or one "yes" answers means your schema is fine and you are looking at a rescue. Three or more means the foundation needs rebuilding, and everything sitting on top of it will need to move regardless of how good it is.

What a rescue actually involves

A rescue keeps your product and fixes what makes it dangerous, in order of severity. The order matters more than people expect, because working on the wrong thing first means polishing an interface while credentials are still exposed.

1. Secrets first. API keys, database URLs and service tokens that are committed to the repository or shipped into the browser bundle. Rotate them, move them to environment variables, and scrub the git history so an old commit cannot leak them later. This is hours of work and it is always the first thing.
2. Authorization second. Every endpoint that assumes the interface already checked who is asking. The classic AI-generated pattern is a route that reads a user id from the request body and trusts it. Anyone can change that number.
3. Money and data-loss paths third. Payment handling, quota enforcement, anything that writes irreversibly. These need tests before anything else gets tests, because these are the failures you cannot apologise your way out of.
4. Error handling fourth. Empty catch blocks make failures silent, which means you find out about them from a customer rather than from monitoring. Replace them with logging and real error responses.
5. Then the rest. Indexes, rate limits, caching, test coverage on the critical paths, and a deployment process that is not one person's laptop.

For most apps we see, that is around two weeks of senior engineering attention. Not a rewrite, and not a heroic effort. Just the parts nobody prompted for, done in the right order.

What a rebuild actually involves

A rebuild does not mean deleting everything. Done properly it means keeping the parts that encode real knowledge and replacing the foundation underneath them.

• Keep: your product decisions, your interface design, your copy, your integrations, and above all your understanding of what customers actually needed. That knowledge cost you months to acquire and none of it is in the schema.
• Replace: the data model, the access layer, and whatever the model shape forced into a bad structure.
• Migrate: the live data, which is the part people forget to budget for. Moving existing customer records into a corrected schema is real engineering, and it is the reason a rebuild costs more than the estimate that ignored it.

A rebuild on a product that already has users is typically four to eight weeks depending on how much data has to move and whether you can run both versions in parallel during the switch.

The three cases where the rule does not apply

There are situations where the schema is fine and you should still rebuild, and one where the schema is wrong and you should not.

Rebuild anyway when the product direction has changed

If what you are building now is meaningfully different from what you prompted for six months ago, you are not rescuing a codebase, you are renovating a house for a family that has moved out. The schema may be perfectly correct for a product you have stopped selling.

Rebuild anyway when nobody can read it

Occasionally we open a codebase where the same logic exists in four slightly different versions, none of them named meaningfully, with no way to tell which one runs. The schema can be flawless and the application still be uneconomic to change. The test is whether a competent engineer who has never seen it can find where a given behaviour lives within an hour.

Rescue anyway when you are pre-revenue and pre-users

If nothing is live and nobody's data is at stake, the schema being wrong costs you almost nothing to fix, because there is no migration. Change it now. The rule about data models is really a rule about the cost of moving data, and with no data there is no cost.

What this costs, and what to ask for

Whoever you hire, ask for the diagnosis in writing before you commit to a direction. A firm that will not tell you which of the two you need, with reasons, before invoicing you for the work, is a firm whose answer is going to be whichever one is more expensive.

The written diagnosis should name the specific schema problems it found, say which of the five questions above came back as yes, and state plainly whether the recommendation is rescue or rebuild. That document is useful to you even if you then take it to a different vendor, which is exactly why it is worth insisting on.

If a supplier tells you it needs a rebuild without showing you the schema evidence, get a second opinion. Rebuilds are more profitable to sell and that is not a coincidence.

The short version

• Ignore how much of the code was AI-generated. It is not the variable.
• Check the schema against the five questions. Zero or one yes means rescue; three or more means rebuild.
• In a rescue, fix in severity order: secrets, authorization, money paths, error handling, then everything else.
• In a rebuild, keep the product knowledge and budget properly for the data migration.
• Get the diagnosis in writing before anyone starts, and make sure it names specifics.

If you want the diagnostic itself, the 30-minute self-check walks through the six tests you can run on your own codebase before talking to anyone. If you would rather have a senior engineer do it and hand you the written recommendation, that is what our vibe code rescue audit produces, and there is a deeper write-up of what we find in AI-generated code specifically.