Rewrite or stabilise? How to decide what to do with an AI-built app

There's a moment almost every founder with an AI-built app ends up living through: bugs pile up, every fix breaks something else, and someone — a developer, a friend, sometimes the AI itself — says "it's best to redo everything".

Sometimes that's true. In most of the cases we see, it isn't.

Why rewriting everything is almost always the wrong call

An app in production has something a new project doesn't: real users and decisions that have already been validated. Rewriting from scratch means months without anything new for customers, the risk of losing business rules that only exist in the code and, often, repeating the same mistakes with a different technology.

Stabilising means something else: keeping what works, fixing what is at risk and improving the structure piece by piece, without stopping the business.

The questions we use to decide

1. Is the data protected? If there are data leaks between customers or misconfigured permissions, that gets fixed first, whatever the decision. It isn't a reason to rewrite — it's a reason to act now.

2. Does the database structure make sense for the business? If the tables reflect the business, even with problems, almost everything can be fixed on top. If the data model is fundamentally wrong, then yes, parts of the app may need to be rebuilt.

3. Are the problems spread out or concentrated? Problems concentrated in two or three areas are solved by rewriting those areas. Problems everywhere, with no pattern, are a stronger sign for a rebuild.

4. How much does maintaining cost compared with rebuilding? If every new feature takes twice as long as it should because of the existing code, that difference is the cost of maintaining. When it's higher than the cost of rebuilding a part, rebuilding that part pays off.

5. Are there tests that tell you when something breaks? Without tests, any change is risky — whether you stabilise or rewrite. Adding tests to the critical parts is almost always the first step.

The path we usually recommend

An audit to know what is really at risk.
Fix the critical issues — data, permissions, security.
Tests and CI so the fixes don't go backwards.
Improve in phases, area by area, and only rebuild what costs more to maintain than to rebuild.

In most cases, the app you already have is a better starting point than a blank page.

Not sure whether your app should be stabilised or rebuilt? Book 30 minutes with us — we'll tell you what we think, even if the answer is "you don't need us".