Rewrite or rescue an AI-built app? A decision guide

Whether to rewrite or rescue an AI-built app depends on the architecture, not the code style. Rescue when the data model, authentication approach and hosting can carry production risk after targeted fixes. Rewrite when trust boundaries are wrong at the foundation, such as business rules enforced only in the browser or a schema that cannot represent real ownership.

Why the rewrite-or-rescue question comes up

AI app builders and coding agents optimize for a visible result. They produce a working screen quickly, and the parts that matter in production, such as authorization, data ownership and failure handling, are invisible in a demo. When the first real users, a payment provider review or a security questionnaire arrive, the team discovers those gaps all at once.

At that point the question is usually framed badly. Developers who inherit the code see unfamiliar patterns and recommend starting over. Founders who paid for speed want to keep everything. Both reactions are about how the code feels, not about what it would cost to make the product trustworthy.

The general hardening path, covering authentication, secrets, payments, monitoring and evaluation, is described in How to turn a Lovable/v0 prototype into a production application. This guide does not repeat it. It focuses on the decision that comes before it: whether that path is cheaper than replacing the foundation.

What teams often get wrong

The most common mistake is judging by code quality. Inconsistent naming, duplicated components and missing tests are real problems, but they are cheap to fix incrementally. On their own they rarely justify a rewrite.

The second mistake is the opposite: assuming that because the app works, only polish remains. An app can work perfectly for one user and still have a data model in which every record is readable by every account.

The third is treating the decision as all-or-nothing. Most AI-built apps have a salvageable interface and product flow sitting on top of a few layers that need replacing. A partial rewrite of the data and permission layer, behind the existing screens, is often the right answer.

Finally, teams skip the inventory. Without a written list of what the app does, which data it stores and who can reach it, any estimate, whether for rescue or rewrite, is a guess dressed up as a plan.

A practical decision framework

Score the app on the layers that are expensive to change later. For each one, ask whether it can be corrected in place, or whether correcting it means touching almost everything built above it.

• Data model: Can the schema represent ownership, tenancy and the entities the business actually has? Renaming columns is cheap. Adding tenant boundaries to every table and query is not.
• Authorization: Are access rules enforced on the server or in the database, or only by hiding buttons in the browser? Client-only checks mean every read and write path needs review.
• Secrets and integrations: Are provider keys used from the browser? Moving them server-side is routine if the calls are centralized and painful if they are scattered through components.
• State and side effects: Do payments, emails and external writes happen exactly once, with retries that do not duplicate work? Or are they fired from interface events with no record?
• Hosting and runtime: Can the platform run the background work, scheduled jobs and server-only code the product needs?
• Product flow: Do the screens and steps match what users need? This is usually the most valuable part of the prototype and the easiest to keep.

If the problems sit mainly in secrets, side effects and hosting, and they are localized, rescue. If the data model and authorization are both wrong in ways that touch every feature, rewriting those layers is usually cheaper than patching around them. If the hosting platform cannot run required server-side work at all, a migration is part of either option.

A useful rule of thumb

Write the rescue as a list of concrete changes, each paired with a test that proves it. If the list keeps growing as you inspect, and most items require schema changes, you are describing a rewrite in pieces. Name it honestly and plan it as one project rather than letting it arrive as a series of surprises.

Implementation considerations

Whichever way you decide, start with an inventory: routes, data collections or tables, third-party services, environment configuration and who can call what. The inventory is the artifact that makes an estimate defensible to a co-founder, an investor or a board.

For a rescue, fix trust boundaries first and cosmetics last. Move secret-bearing calls to server routes, add database-level access rules, make payment and webhook handling idempotent, then add logging you can read. The order matters because each step reduces the risk of the next deployment.

For a rewrite, keep the prototype running as the specification. Port the flows users rely on, migrate data with a script you can rerun, and switch traffic only after the new system passes the same scenarios. Rewrites fail most often when the old app is switched off before the new one handles the edge cases the prototype had already discovered.

In both cases, protect what already works. The prompts, copy, screen flows and discovered edge cases are knowledge. The point made in the limits of building agents only from vibe-code tools applies to whole apps too: the prototype stays an asset when you plan explicitly for what gets replaced.

Trade-offs

Rescue is faster to first value and keeps momentum, but you inherit decisions you did not make. Some will surface later as friction, and the team has to accept a period of mixed patterns while old and new code coexist.

A rewrite gives a clean foundation and a codebase the team understands, but it pauses visible progress, carries migration risk and tends to rediscover problems the prototype had already solved. It also invites scope creep: a rewrite is a tempting moment to add features nobody has validated.

A partial rewrite, with a new data and permission layer under the existing interface, combines some of both. It needs careful boundaries so the old screens can talk to the new layer without leaking the old assumptions back in.

Lessons from ImadDhin work

These are implementation and code-level observations from work we can show publicly. They are not claims about client outcomes.

In the ImadDhin portal, a CRM integration handler was inspected and found to write campaign text into a provider-managed field and to assume custom properties existed. The fix was a targeted change to the mapping and to response checking, not a rewrite of the lead flow. The surrounding form, storage and analytics chain was sound, so replacing it would have added risk without benefit.

The site's pricing page shows the same instinct on a smaller scale: retired tiers are hidden behind a flag in code rather than deleted, so the change is reversible. Change what users see, keep options open, and delete only when you are sure nothing depends on it. For anything that handles money or access, retire old server routes deliberately rather than leaving them reachable.

The public FoCoCo case study describes a Phone App and a WebApp on one backend. Adding a second client meant building against the existing identity and data rather than standing up a parallel system, which is the same instinct that favors rescue when the foundation is sound.

Common mistakes to test for

Before choosing, run a short set of checks that reveal foundation problems quickly.

• Sign in as two different accounts and try to read or change the other account's records through the API, not through the interface.
• Search the built client bundle for provider keys and private endpoints.
• Replay a payment or webhook event and check whether it creates a duplicate order, credit or email.
• Remove a required configuration value in a staging deploy and confirm the app fails clearly instead of silently falling back.
• Run the main flow with a slow or failing third-party service and see whether the user gets a usable message.
• Check whether data can be exported and migrated with a script rather than by hand.

If most of these pass, or fail only in isolated places, rescue is likely viable. If the cross-account test fails everywhere, the authorization layer is the project, and your estimate should say so.

When a simpler solution is better

Not every AI-built app needs either path. If the app is an internal tool for a handful of trusted people with no sensitive data, a short hardening checklist and reliable backups may be enough.

If you are still testing whether anyone wants the product, keep iterating in the builder and delay production work until the flow is validated. Spending on architecture before demand is known is its own risk. And if an off-the-shelf tool now covers the core workflow, retiring the prototype can be the cheapest option of all.

Get a clear answer before you commit budget

The decision is easier with an inventory and a short list of tests than with opinions about code style. If you have an AI-built app and need to know what survives, see how vibe-code rescue engagements are structured, or bring the repository to a 30-minute call. You can also start a brief and choose the option for an existing prototype.