When the AI-written code has become the problem.

• Every change breaks something else

  You ask the AI to fix the date picker and the login stops working. Fixes start to undo earlier fixes, and nobody can say which version was the last good one.

• Nobody understands the structure

  The same logic exists in three places, files have thousands of lines, and a new developer needs weeks before they dare to change anything.

• Costs climb without more users

  The hosting, database or model bill grows faster than your customer base, for example because of polling, missing indexes or calls that run on every page load.

• The builder no longer helps

  The AI tool runs in circles, hits context limits or rewrites working code. Progress depends on luck rather than on a plan.

• You cannot hand it over

  A developer you want to hire, or an investor’s technical team, asks for the repository, the tests and the deployment process, and there is little to show.

A rescue follows a fixed order. Each phase produces something you keep, even if you stop after it.

1. 1

   Map what exists

   We read the code, the database schema and the deployment and draw a map: which parts carry the business, where data flows, and which parts are dead or duplicated.

   Output System map and risk list

2. 2

   Stabilize

   Freeze the moving parts: version control with a known-good state, separate environments, secrets moved out of the code, and the SEV-1 security issues closed first.

   Output A baseline you can return to

3. 3

   Test the critical paths

   Before anything is restructured, sign-up, payment and the core workflow get automated tests. They make the next changes safe, whether a person or an AI agent makes them.

   Output Tests that run on every change

4. 4

   Decide: refactor or rebuild

   With the map and the tests in place, we decide together, part by part, what to clean up and what to replace. A full rewrite is the exception, not the default.

   Output A written decision per area

Refactor or rebuild: how the decision is made

Refactor when

the data model is sound, the main workflows work, and the problems sit in structure, duplication and missing tests.

Rebuild a part when

the data model itself is wrong, a component cannot be secured, or every change to it costs more than replacing it.

Keep as is when

the code is ugly but stable, rarely changes and is covered by tests. Not every mess needs to be cleaned up now.

AI app builders are a good place to start, but a business needs its code in a place it controls, with a history, a review process and a way for other developers to work on it. The handover covers these steps:

1. Export the project from Lovable, Bolt or v0 into a GitHub repository that belongs to your company account, not to a personal login.
2. Make the app build and run outside the builder: a README, environment variables documented, a local setup that a new developer can follow.
3. Move database migrations, storage rules and edge functions into the repository, so the backend is versioned along with the code.
4. Set up deployment from the repository with a preview or staging environment, and move secrets into the hosting provider’s secret store.
5. Hand over to your developers or a new hire with a walkthrough of the system map, the open risks and the test suite.

Imagine a founder whose app lives in a builder account under a personal email address. If that account is locked, the product is locked with it. Moving the code into a company repository can be one of the cheapest risk reductions available.