Rescue, refactor or rewrite? How to decide what to do with an AI-built codebase

Should you rescue, refactor or rewrite an AI-built app?#

In most cases, rescue first. If users can complete the core flow and the data model roughly matches the business, the fastest and least risky path is to fix security, configuration and reliability in place, then refactor the parts you change most often. A rewrite is justified only when the foundation itself is wrong, and it should almost always be done incrementally.

That answer frustrates people on both sides. Founders who are tired of the AI-generated code want a clean start. Engineers who inherit it often want the same thing, because rewriting feels more productive than reading. But the code you can see is rarely the expensive part. The expensive part is the behaviour nobody wrote down — the edge cases users already rely on, the data already in production, the integrations that work for reasons nobody remembers.

"Almost right" is the normal state of an AI-built app at launch. Almost right is usually fixable. The question is how much of the foundation is in the "almost".

What do rescue, refactor and rewrite actually mean?#

They differ in what changes and what stays. Rescue changes the minimum needed to run safely in production. Refactor changes the internal structure without changing behaviour. Rewrite replaces the implementation, and usually the data model, while trying to preserve behaviour.

• Rescue — close security holes (authorization, leaked secrets, unverified webhooks), fix configuration, add error monitoring, backups and tests around critical flows. The architecture stays.
• Refactor — restructure code that slows every change: duplicate logic, components that do five things, business rules scattered between UI and database. Behaviour stays; tests prove it.
• Rewrite — build a new implementation, often on a different data model or platform, and migrate users and data to it.

Which signals point to each option?#

Look at the data model and the change history before you look at code style. Ugly components are cheap to fix. A schema that cannot represent your business is not.

Signals for a rescue

• [ ]Users can complete the main flow end to end.
• [ ]The tables roughly match the real-world things you sell or manage.
• [ ]The problems you know about are security, deployment, payments, error handling or performance hot spots.
• [ ]You can name the five flows that matter and they mostly work.

Signals for a refactor

• [ ]Small features take days because the same logic exists in several places.
• [ ]Fixing one bug reliably creates another nearby.
• [ ]Most churn concentrates in a few files or modules (check git log --stat).
• [ ]Nobody, human or AI, can change a part of the app without reading all of it.

Signals for a rewrite

• [ ]The data model is wrong at its core — for example, single-user tables for what must be a multi-tenant product, or money stored as floats across the schema.
• [ ]The platform cannot do what the product needs (a no-code backend that cannot run the jobs, compliance or integrations you have signed up for).
• [ ]Data integrity cannot be trusted and cannot be repaired in place.
• [ ]There is little real usage yet, so there is little behaviour to preserve.

What does each option really cost?#

The direct cost is engineering time. The bigger cost is what that time displaces. Debt you leave in place keeps taxing every future feature; a rewrite pauses the roadmap and spends money rebuilding what already exists.

That is the argument against ignoring the problem, not an argument for a rewrite. A rewrite has its own costs that are easy to underestimate:

• Feature freeze. While the new system is being built, the old one gets only urgent fixes, and competitors keep shipping.
• Rediscovered requirements. Every quiet edge case the old app handled has to be found again, often by users.
• Data migration. Moving production data to a new schema needs scripts, rehearsals, validation and a rollback plan.
• Two systems. Until the cut-over, you pay to run, monitor and secure both.

Rescue and refactor costs are easier to bound, because each change is small and can be priced and verified on its own. That is why we structure them as fixed-scope sprints rather than open-ended hourly work.

If you must rewrite, use the strangler fig pattern#

The strangler fig pattern, described by Martin Fowler, replaces a system piece by piece instead of all at once. You put a routing layer in front of the existing app, build one capability in the new system, send that traffic to it, and repeat until the old system has nothing left to do. The old app keeps serving users the whole time.

1. Put a seam in front. A reverse proxy, edge middleware or API gateway that can route by path or feature.
2. Pick the first slice. Choose something valuable and well-bounded — often the area with the worst bugs or the most change.
3. Build it new, with tests. Include the data it owns, and decide how data syncs with the old system during the transition.
4. Route traffic gradually. Behind a feature flag, to internal users first, then a percentage, then everyone.
5. Delete the old code path. A slice is finished when the old implementation is gone, not when the new one exists.

// Next.js proxy (middleware) as the strangler seam:
// migrated paths go to the new service, everything else stays on the old app.
import { NextResponse, type NextRequest } from "next/server";

const MIGRATED = ["/billing", "/api/invoices"];

export function proxy(req: NextRequest) {
  const path = req.nextUrl.pathname;
  if (MIGRATED.some((p) => path === p || path.startsWith(p + "/"))) {
    return NextResponse.rewrite(new URL(path + req.nextUrl.search, process.env.NEW_SERVICE_URL));
  }
  return NextResponse.next();
}

The routing is the easy part. The hard part is data. While both systems run, each piece of data needs exactly one owner: either the new service reads and writes it and the old app goes through the new service, or the old database stays the source of truth and the new code reads from it until cut-over. Writing the same records from both systems without a clear owner is how strangler migrations end up with drift that nobody can reconcile. Decide ownership per slice, write it down, and add a check that compares the two sides until the old path is deleted.

The pattern turns one large, all-or-nothing bet into many small, reversible ones. If a slice goes badly, you route traffic back. If priorities change halfway through, you still have a working product.

How to make the decision with evidence#

Decide after a short, structured audit, not after a gut reaction to the code. An audit should answer four questions in writing: what is dangerous right now, what is slowing you down, whether the data model can carry the next stage of the product, and what each option would cost in sprints.

If you cannot point to the part of the foundation that cannot be fixed in place, you do not need a rewrite yet.

This is how our Rescue Audit works. It is fixed-price at €690 and takes 3 business days. We review the repository, the database and its policies, auth, payments, deployment and monitoring, then deliver a prioritised risk map and a recommendation — rescue, refactor or rewrite — with the reasoning written down. If you continue with us, the audit fee is credited 100% to the rescue. Rescue and refactor work then runs in fixed-scope 2-week sprints from €4,900.

We do not recommend a rewrite unless the audit proves it in writing. Not because rewrites are always wrong, but because the burden of proof should sit with the most expensive option.

How Backloo can help#

Start with the free 60-second readiness check to see which areas look weakest. If you want a full, written verdict, the vibe code rescue page describes the audit and the sprints that follow, and backend systems covers the cases where the foundation really does need replacing. The code, the repository and the cloud accounts stay yours throughout. If the problems are mostly production readiness, our pre-launch checklist and Supabase RLS checklist may be all you need — or get in touch and describe what you have.