Should I fix my AI-built app or rebuild it from scratch?

Nearly everyone who asks me this question asks it in the same week: the week after something broke badly, or the week a developer looked at the project and made a face.

That timing matters, because it means the decision is being made at the emotional low point of the project, and "start again, properly this time" is an enormously attractive thought when you are tired of an app that keeps surprising you. It feels like control. It is also, most of the time, the more expensive of the two options and the one more likely to end in the same place.

So here is the structural version of the question, which gives a different and more reliable answer than the feeling does.

First: what are you actually deciding about?

The instinct is to treat the code as the asset — you paid for it, in credits or in months, so throwing it away feels like the loss.

It is not the asset. In an app that is already live, the code is the least valuable and most replaceable thing you own. What is actually valuable is your live users and their accounts, your real data, your payment history and subscription state, your domain and its search presence, and the accumulated knowledge of what people actually do in the product versus what you assumed they would.

A rescue puts none of that at risk. A rebuild puts all five in play at once, because every one of them has to be migrated, and migrations are where the genuinely dangerous mistakes live. That asymmetry is the whole reason to be conservative here, and it has nothing to do with the quality of the code either way.

If your app has no users and no real data yet, most of this section does not apply to you and a rebuild is a much cheaper decision. Say so plainly to anyone advising you, because it changes the answer.

The rebuild trap

Here is the failure I have watched more than once, and it is worth being explicit about because it is not obvious in advance.

Someone decides the app is beyond saving. They start again — often with the same tool, sometimes a different one, usually with the same brief but "done properly this time". Six weeks later they have a cleaner codebase that they understand better, that has been built by the same generate-and-look loop, and that is missing the same access policies, the same idempotent webhook handler, the same indexes, the same error tracking and the same staging environment.

The gaps were never a property of the code. They were a property of the process that produced it. Rebuilding changes the code and leaves the process alone, so it reproduces the gaps faithfully. The version-two app is prettier and it fails the same audit.

That is why "the code is messy" is not a rebuild reason on its own. If the reason you are starting again is quality, the thing that has to change is what gets checked at the end — and if you are changing that, you can apply it to the app you already have and keep your users.

The five tests

Two of these can justify a rebuild by themselves. The other three cannot, no matter how bad they look.

Test one: is the data model wrong at the root? This is the real one. Not "the table names are ugly" — genuinely wrong, in the way that makes correct behaviour impossible to express. The classic version is an app that assumed one user per account and now needs teams: there is no organisation anywhere in the schema, ownership is a single user column on every table, and every screen, policy and query assumes it. Adding teams to that is not a feature, it is a change to the meaning of every row you have.

If your growth plan requires a relationship the schema cannot represent, that is a legitimate rebuild trigger — although even here the honest version is usually a data migration plus a partial rewrite rather than a blank page.

Test two: is there a platform ceiling you cannot buy past? Sometimes the constraint is not the code but where it lives. You need a background job that runs for ten minutes and the platform caps functions at sixty seconds. You need a database extension the managed backend does not expose. You need to be in a specific region for data-residency reasons and cannot choose one. You need a security certification and the platform will not sign the paperwork.

These are real and they are not solvable by writing better code. But notice what they justify: moving, not rewriting. Which is the point of the section after next.

Test three: the code is messy and nobody understands it. Not a rebuild reason. This is a reading problem, and reading somebody's app end to end is days, not months. Generated code is generally conventional rather than exotic; what makes it feel impenetrable is usually that it is undocumented and inconsistent, both of which survive a rebuild by the same means.

Test four: the security is bad. Not a rebuild reason, and this is the one that surprises people most. Access control in a modern backend lives in database policies, not in application code — so rewriting the application does not fix it and does not need to. You would write exactly the same policies against exactly the same tables in the new version. Do it now, against the app you have, and it protects your live data this week rather than in two months. The five-minute check for whether you have this problem at all is in is my Lovable app secure?

Test five: it is slow and it breaks. Not a rebuild reason. Slowness in these apps is overwhelmingly three query patterns and a lack of indexes, all of which are fixable in days and none of which are architectural. Rebuilding does not remove them either — the same tool generates the same lookup-inside-a-loop in the new version, because that pattern is what "show each item's author" naturally produces. The detail on that is in why your app breaks when real users show up.

So: two structural triggers, three feelings. If your reason is on the second list, you have a rescue.

The option nobody considers

The framing "rescue or rebuild" is a false binary, and the third answer is usually the best one.

You can rebuild a subsystem at a time, behind the app that is running. Stand up the new piece, move traffic to it for one part of the product, confirm it works with real users on it, then do the next one. The database is often the last thing to move, or never moves at all.

This is slower on paper and much faster in practice, for three reasons. You are never holding two versions of the truth and trying to keep them in sync. You are never in the multi-week stretch where the old app is unmaintained and the new one is not ready, which is where most rebuilds actually die. And you can stop at any point — if two subsystems in you conclude the rest is fine, you have lost nothing.

It is also the only version of this that is compatible with having paying customers throughout, which for most people reading this is not optional.

What a rescue actually looks like

Concretely, so it is not an abstraction:

First, contain. Rotate any credential that has been somewhere it should not have been, and switch on row-level security wherever user data lives. This comes before everything because it is the only category where the damage grows with time rather than with traffic — a leak does not need users, it needs days.

Second, see. Error tracking on both server and browser, one alert on the flow that matters most, and a verified backup you have actually restored once. Roughly an hour of work, and after it every subsequent decision is made on evidence instead of guesses.

Third, stop the bleeding on changes. A staging environment, so changes stop being tested on customers, and tests on the two or three flows that would cost real money if they broke. This is the step that ends being stuck, because being stuck is a change-cost problem more than a feature-difficulty problem — the mechanism is set out in stuck at 80%.

Fourth, fix what is actually costing you. The slow screens, the payment edge cases, the authorization holes. In that order, because by now you have the data to know which is which.

Fifth, decide about ownership deliberately. Where the code lives, whether the database can leave, what is in an export and what is not — as a choice rather than a discovery. That is its own subject, in what you actually own when you export.

Notice that almost nothing in that list would be thrown away by a later rebuild. The policies, the indexes, the webhook handling, the monitoring and the backups all live in the database and the infrastructure. That is the practical argument for doing them first regardless of what you eventually decide: it is the work that survives the decision.

The honest cases for rebuilding

I would rather not write a page that concludes "always hire me to fix it", so here are the cases where I would tell you to start again.

Your data model cannot express the product you are now selling, and the migration to fix it touches every table — at that point you are rebuilding anyway, and doing it deliberately is better than doing it accidentally.

You have no users and no real data. The entire conservative argument above rests on having something to lose. Without it, a clean start is cheap and often genuinely faster.

The app was a throwaway proof of concept and everyone involved always knew it. Some things are built to answer a question, and the answer being yes is not a reason to keep the prototype.

You need to leave the platform for a hard external reason — residency, certification, a technical ceiling — and the app is small enough that moving it and rewriting it are similar amounts of work. Below a certain size that is true and worth taking.

Outside those, I would want a specific answer to test one before agreeing to start over.

What it costs, roughly

The reason this decision matters financially is that the two options have completely different shapes.

A rescue is bounded and front-loaded: a known list, done in priority order, with the highest-value items in the first few days, and you can stop when the remaining items stop being worth it. It also happens with the app live and earning throughout.

A rebuild is unbounded and back-loaded: you get nothing until the end, the end date is an estimate made before anyone has read the old app closely, and the migration — the genuinely risky part — is the last thing to happen, which is precisely the worst place to put your riskiest step. Meanwhile the old app is running unmaintained and the new one is absorbing everything.

For what the surrounding infrastructure costs either way, there is a line-by-line breakdown in what it costs to take an AI prototype to production in 2026, and if you are about to hire someone for either job, the questions worth asking are in how to hire someone to fix an AI-built app.

If you want a second opinion before deciding

This is a decision worth spending an hour on before spending two months on it.

I do a Production-Ready Audit that ends in exactly this answer: whether the data model can carry where you are going, which of the ten common gaps your app actually has, and a written fix list in priority order with honest costs — including, where it is true, the sentence "this needs rebuilding and here is specifically why". From $499, back in five to seven days.

And if you just want a sanity check before committing to anything, describe your data model in a few sentences and what you need it to do next, and I will tell you whether test one is triggered. No charge. It is a five-minute question and telling someone to rebuild when they do not need to is an expensive way to be wrong.

More on the repair work itself is on the AI SaaS rescue page, on finishing a stalled build on the MVP development page, and the full list of what tends to be missing is in the ten problems every AI-built app has in production.