Rewrite or Salvage? What's Actually Worth Keeping in an AI-Built App

You built something with AI. It worked, people started using it, and then it stopped being fun: a bug you cannot find, a page that times out, a customer who saw data that was not theirs. So you asked a developer, and the developer said what developers almost always say.

"You should rebuild it properly."

Maybe they are right. But that sentence is also the easiest advice in software to give, the most profitable advice to give, and the hardest to check. Before you spend a rebuild's worth of money and calendar, it is worth knowing what in your app is genuinely worth keeping, because it is usually more than you have been told, and it is almost never the part you were proudest of.

Why "rewrite it" is the default answer

Three reasons, and only one of them is about your code.

Reading code is harder than writing it. Understanding somebody else's system means holding a stranger's decisions in your head until they make sense. Starting fresh feels faster because the difficulty moves from thinking to typing. It is genuinely more pleasant. It is not genuinely faster.

A rewrite is a clean scope. "Rebuild this in four months" is a proposal anyone can write. "Work out which third of this is dangerous and fix that" requires looking first, which is unbillable, uncertain, and much less comfortable to quote.

AI-generated code triggers it faster than human code. It tends to look tidy and read fluently while being wrong in specific structural ways, which produces a strong reaction in an experienced reader: this cannot be trusted, start again. The instinct is right about the trust. It is often wrong about the scope.

Split the app into four layers and judge each one separately

The mistake in this decision is treating the app as one object that is either good or bad. It is four things, and they are usually in wildly different condition.

Layer 1: the product decisions. What the thing does, the flow a user walks through, the fields on the form, the words on the buttons, the pricing. Nobody counts this as an asset because it is not code, and it is the most valuable thing you own. Every one of those decisions was made and then tested against real people. A rewrite keeps this for free, and a rewrite that quietly redesigns it is not a rewrite, it is a second product with the first one's risks.

Layer 2: the data model. The tables and how they relate. This one genuinely splits. Often it is reasonable, or reasonable enough that fixing it means adding constraints rather than starting over. Sometimes it is the whole problem: no clear owner on records, no separation between customers, values stored in ways that quietly lose meaning. This is the layer to look at first, because it is the one that gets more expensive to change with every day of real data you add.

Layer 3: the application code. The mixed bag, and the layer everyone judges the app by. Some of it will be perfectly ordinary. Some will be duplicated five times with small variations. Some will be inexplicable. Volume here is not the issue; the issue is whether it is the kind of code you can change without fear, which is mostly a question about layers 2 and 4.

Layer 4: the wiring. Authentication, authorisation, secrets, deploys, backups, environments. In AI-built applications this is reliably the weakest layer, because it is the part that never shows up in the demo, so nothing during the build ever pushed back on getting it wrong. It is also the cheapest layer to replace, because it is standard work that thousands of applications need in the same shape.

Notice what that pattern means. The layer most likely to be broken is the layer least likely to require a rewrite.

The signals that say salvage

Any of these, and starting over is probably the expensive option:

• It has real users and real data. Every day it stays live, the data becomes more valuable and more entangled, and a rewrite has to carry it across.
• It makes money, even a little. A rewrite means months where nothing improves for the customers currently paying you.
• You can run it locally. If a developer can get it running in an afternoon, it is legible enough to work with.
• It uses mainstream tools. A common framework with a common database is a system any competent developer can join. This is the ordinary case for AI-built apps, because the models were trained on the popular choices.
• You can describe what it does in a page. Small scope means the dangerous surface is small too.

The signals that say something has to be replaced

Note the wording. These are triggers to replace a layer, not the app. Each one is a specific finding, not a vibe:

• Authorisation decided in the browser. If what a user can do is enforced by which buttons the page shows them, it is not enforced at all. Anyone can call your API directly.
• No separation between customers' data. If the only thing stopping customer A reading customer B's records is that every query happens to filter correctly, then one missed filter is a breach. This is the single most common serious finding in AI-built products, and the most expensive to retrofit later.
• Secrets shipped to the client. API keys in the front-end bundle are public, whatever the code looks like. Rotating them is quick. Finding out what was done with them is not.
• No backups you have ever tested. A backup nobody has restored is a belief, not a backup.
• A platform you cannot get your code out of. This is the one true forced rewrite. If the app only exists inside a builder that owns the runtime, your options are bounded by that product's roadmap, no matter how good your code is.

The middle path nobody sells you

Most real answers are neither "keep it" nor "start again". They are: keep the data and the product, replace the dangerous layer, ship the change in stages while the thing stays live.

That is unglamorous and it is usually correct. Move authorisation to the server, one endpoint at a time, highest-risk first. Add the missing isolation to the data model before there is ten times more data. Put real backups in place this week, because that is a day of work and not a project. Then, and only then, decide whether the application code is worth tidying at all, which is a question about how much you plan to change it, not about how it reads.

The reason this path is rarely proposed is not technical. It is that it is harder to scope, harder to quote, and less satisfying to sell than a clean rebuild.

What the rewrite quote leaves out

If you do choose a rewrite, price it honestly, because three real costs tend to sit outside the number:

You rebuild the parts that were fine. The rewrite does not know which two thirds were harmless, so it pays to recreate them anyway.

You rediscover the requirements nobody wrote down. Your current app contains dozens of small decisions that only exist as code, and each one gets relearned, usually by a customer noticing it is missing.

You run two systems during the migration. Two deployments, two sets of data, and a cutover, all while the old one still has to work. This phase is where rewrites overrun, and it is almost never in the estimate.

None of that makes a rewrite wrong. It makes the comparison fair.

How to decide in a week instead of a month

The decision needs three facts, and none of them require a rebuild to discover: what your data model actually looks like, whether authorisation is enforced on the server, and whether anything in the app can leak between customers. Answer those and the choice usually makes itself, because the expensive scenarios and the cheap ones stop looking alike.

That is exactly what our free AI code audit is for. Read access is enough, nothing in your code changes, and you get a written verdict on what is solid, what is fragile and what is dangerous, in 48 to 72 hours, yours to keep whether you hire us, hire someone else, or fix it yourself with the list in hand.

What you should not do is make this call on instinct, in either direction. "Rebuild it properly" and "it is fine, ship it" are both guesses, and one of them costs you a quarter while the other costs you a customer's data. The app you have is evidence. Read it before you replace it.