Rescue or rebuild: what should you do with an AI-built codebase?

Founders usually ask this question after the third fix that broke two other things. By then it feels like a rebuild, because the code has stopped being something anyone can reason about. That feeling is not the answer. In our judgement most are worth saving, and the decision rests on a few things that can be checked, which is why we make it in the audit, in writing, before any work is priced.

The signs that point to rescue

• The product works and people use it. Users, data and habits are the expensive part of a product. A rescue keeps all three.
• The data model holds. You can name the main things the product is about (accounts, orders, bookings, whatever yours are) and each lives in one place, with relationships that make sense. Tables can be tidied; a model that is right in shape does not need replacing.
• The problems are in the gaps a demo never shows. Exposed keys, endpoints anyone can call, missing validation, no tests, no staging, no rollback, no monitoring. These are serious, but none of them is a reason to start again. They are work that was skipped, and skipped work can be added.
• The bugs are local. A fix breaks something nearby, not something on the other side of the product.

The signs that point to rebuild

• The data model cannot carry the next feature. The same thing is stored three ways in three places, or the shape is wrong for where the product is going: built for one user when the roadmap needs teams, or for one seller when it needs a marketplace. Every feature after that point is built against the model rather than on it.
• The permissions cannot be expressed. Who may see and change what is scattered through the interface instead of enforced in one place, and adding a role means touching everything.
• The framework fights the product. The tool chose a stack for the demo, and the product needs something it does badly: work that runs on a server on a schedule, payments with webhooks, heavy data, a mobile app. Each workaround costs more than the last.
• Nobody can tell what the code is for. Not messy, which most code is, but contradictory: two implementations of the same rule, disagreeing.

The middle path

Often the answer is neither. The parts of an AI-built app that are not worth saving are usually the data model and the permissions, and those can be rebuilt inside a rescue: a new model and a new auth layer, with the data migrated across, while the screens, the flows and most of the code around them stay. The product does not stop, the users keep their accounts, and the part that was going to block every future feature is replaced once, properly.

This is the answer we give most often when the model is wrong but the product is right.

What each one costs

	Rescue	Rebuild the model and auth inside a rescue	Rebuild
When it fits	The product works and people use it; the code underneath is the risk	The product is right, the data model or the permissions are not	The model, the permissions or the framework cannot carry the next feature, and the audit says so
Money	Stabilisation from $10k; a full rescue $20k to $50k, priced from the audit	Priced as part of the rescue, from the audit	Usually more than a rescue, but less than a rescue that turns into a rebuild halfway
Time	Days to stabilise, weeks to harden, with the roadmap moving	Within the rescue, in increments	A two-week product sprint, then a fast build of under two months or an explore build of two to four
What you keep	The product, the users, the data and most of the code	The product, the users, the data and the code around the model	The product idea, the users and the data; the code starts again

Two things about the rebuild column. A rebuild is a build, priced the same way: a fixed quote at the end of the sprint, from an agreed scope. And it is not quick because the first version was. Our own multi-sided builds, AnyoneGroup and CachePay, each took six months with four people; AnyoneGroup started from a clickable prototype and written descriptions of how everything should behave. A working AI-built app gives a rebuild more than that: the screens, the flows and what users actually did with them. It does not make the backend shorter.

There is a fourth option, keeping going as it is. It fits a prototype, an internal tool, or anything with no real users or money on it yet. It costs nothing today; the bill arrives later as the breach, the outage or the rewrite under pressure.

How we decide in the audit

The audit reads the architecture, the data model, auth and permissions, secrets, dependencies, test coverage and deployment. The decision comes from a handful of questions:

1. Does the product work for the people using it now?
2. Can the data model carry the next three things on the roadmap without being bent?
3. Can every permission the product needs be enforced in one place?
4. Does the framework suit what the product has to do next, not what the demo had to do?
5. Is repairing what is there cheaper than replacing it, counting the users and data a rebuild has to move?

Yes to all five is a rescue. A no on the second or third, with yeses elsewhere, is usually the middle path. Noes on the fourth and fifth are a rebuild.

The one rule

The audit says which before anyone pays for either. It is free, written and back within 24 hours, ranked by what breaks first, and it ends with a straight answer on refactor or rebuild and what each costs. If starting over is cheaper than saving it, you hear that before you spend anything, and the report is yours whether or not you hire us.