Should you fix your AI-built app or rewrite it?

Usually, fix it. An app that works for its first users has already answered the hardest question, whether people want it, and most of its code is fine. A rewrite makes sense when the data model is wrong for the business, or when every change breaks something else. Here's how to tell which one you have.

Why a rewrite is tempting

Developers like rewrites: a clean start, their own choices. Founders hear "the code is a mess" and reasonably think "start again". But a rewrite means months with no new features, finding again the bugs the old app already fixed, and losing small details users rely on without knowing it.

This isn’t new. Joel Spolsky called rewriting from scratch "the single worst strategic mistake" a software company can make, back in 2000, about Netscape. AI tools make writing code cheap, which makes starting again feel cheap too. Getting the new version to where the old one already is still isn’t.

Signs a fix will do

• ✓Users can do the main thingSign-up, the core action and payment work. The problems are at the edges: errors, slow pages, odd states.
• ✓The problems are specific"Some orders don't get marked as paid" or "the dashboard is slow" are bugs with causes. They get found and fixed one at a time.
• ✓The database makes senseThe tables match the things in your business (users, teams, orders, invoices), even if the code around them is untidy.
• ✓Changes are slow, not impossibleGiant files and copied code make every change take longer. They can be split up gradually, while the app keeps running.

Signs part of it needs rebuilding

• ✓The data model is wrongYou sell to teams, but everything belongs to one user. Money is stored in a way that rounds. When the core shape of the data is wrong, most code that touches it changes anyway.
• ✓Every change breaks something elseThe same logic lives in ten places, and fixing one bug makes two. Past a point, fixing that part costs more than rebuilding it.
• ✓The platform can't do what you needYou need offline mobile, long background jobs, or data kept in a particular country, and the stack the tool chose can’t do it.

Even then, it is rarely all or nothing. Rebuild the part that is wrong and keep the rest.

The usual way is what Martin Fowler named the strangler fig: build the new part beside the old one, move one feature or route across at a time, and switch the old part off when nothing uses it. Users keep a working app the whole way.

How to decide without guessing

1. 01Write down where you need to be in six monthsHow many users, which features, which customers. A rewrite only pays off if the current app can’t get there.
2. 02Get the app auditedSecurity, data model, the main flows, deploys and speed, written up area by area. Opinions from someone who hasn’t read the code are guesses.
3. 03Price fix against rebuild for each areaBilling might need rebuilding while the rest only needs cleaning. Decide per area, not for the whole app.
4. 04Do security first either wayOpen database rules and exposed keys are urgent whatever you choose. They don’t wait for the rewrite.

What a fix usually looks like

1. 01Close the security holes: database rules, keys in the browser, checks on the server. My Supabase checklist lists them.
2. 02Add error tracking, so you hear about failures before your users tell you.
3. 03Split the biggest files, and add types and tests around money and sign-in.
4. 04Set up a deploy you can repeat, with a staging copy to test on.
5. 05Then search and speed.

That's the order I work in on a fix: keep what works, fix the rest in order of risk, and leave code that you, the next developer or your AI tool can keep building on.