Your AI-built app broke in production. Repair or rebuild?

Before you rebuild an AI-generated app, stop the damage and keep the evidence. A rushed restart erases the clues that explain the failure. A rushed patch leaves money and customer data less reliable than they were an hour ago. Neither is a decision. Both are reflexes.

Lovable, Bolt, v0, and similar tools are good at turning a product idea into a convincing interface. Production exposes a different class of work: permissions, migrations, retries, payment state, secrets, monitoring, and failures that happen across multiple systems.

First, decide whether this is an incident or an inconvenience

A clipped button and a charged customer with no order are both bugs, but they should not share a queue. Start by describing the possible harm. Money, data loss, account access, privacy, and irreversible actions come before visual defects.

If the app is actively creating harm, disable the specific action. Pause checkout, hide a destructive admin control, revoke a leaked key, or put the affected workflow into read-only mode. Do not take the whole site down when one contained path can be stopped safely.

• Critical: customer money, private data, unauthorised access, or destructive writes
• High: core workflow blocked with no safe workaround
• Medium: degraded workflow with a clear workaround
• Low: visual, copy, or non-critical interaction defect

Preserve the evidence before changing the code

Record the production URL, exact time, affected account, expected behaviour, actual behaviour, browser or device, and any provider identifiers. Export logs before retention windows remove them. Take a database snapshot if a migration or destructive write may be involved.

Then tag the deployed commit. If the platform deploys from a branch automatically, confirm which commit is actually live. AI-generated projects often contain several preview deployments and environment files, so the code you are reading may not be the code users reached.

Reproduce the critical path with one controlled account

Do not click randomly through the app. Write the shortest path that demonstrates the failure. Include the precondition, action, external service, expected database change, and visible result.

A path such as new user signs in, starts checkout, pays, returns, and receives premium access can be tested at each boundary. That reveals whether the issue starts in the browser, API, provider, webhook, database, or permission layer.

A reproducible five-step failure is worth more than fifty screenshots of the final error.

Audit the generated architecture, not the visual polish

An app can look complete while its backend is a set of happy-path assumptions. Inspect where trust lives. Can the browser set a paid flag? Can any signed-in user call an admin endpoint? Does the database enforce relationships, or does the interface merely hide invalid options?

Check authentication, authorization, schema constraints, server-side validation, secrets, file uploads, background work, third-party callbacks, and deployment configuration. These are the areas where a generated first pass needs deliberate engineering.

• Authentication proves identity; authorization proves permission.
• Server code validates every value the browser sends.
• Database constraints protect state even when application code fails.
• Secrets exist only in protected server environments.
• External events are verified, idempotent, logged, and replayable.
• Production errors create an alert with enough context to act.

Choose keep, repair, or rebuild by cost of risk

Keep the system when the architecture is sound and the defect is isolated. Repair it when the core can support the product but one or more critical flows need deeper work. Rebuild the unsafe core when data ownership, permissions, or payment state cannot be made reliable without replacing most of the path.

Do not use code style as the deciding factor. Untidy code can still be repaired. A beautifully organised app with client-controlled authorisation may need a fundamental rebuild. The question is whether each critical guarantee can be proven and maintained.

If you repair, work in testable slices

Lock the current behaviour with a failing test or a scripted reproduction. Make the smallest change that fixes the unsafe boundary. Test the complete user path, deploy behind a controlled release where possible, and watch logs and data after release.

Avoid a giant cleanup branch that changes routing, styling, database access, and payments at once. Rescue work succeeds when each slice has one reason to exist and one way to prove it worked.

If you rebuild, protect the product and the data

A rebuild should not mean starting the business from zero. Preserve approved user flows, copy, visual assets, domain knowledge, analytics events, and data that can be migrated safely. Write a migration plan before building the replacement schema.

Run old and new systems in parallel for a short controlled period if the risk justifies it. Reconcile data, test rollback, and switch one workflow at a time. The goal is a safer product, not a dramatic rewrite announcement.

• Define the production guarantees the new core must enforce.
• Map old data to the new schema and record rejected rows.
• Rebuild the highest-risk path first.
• Test payments, auth, permissions, and destructive actions end to end.
• Prepare rollback and customer-support instructions before launch.

Add the operating layer the first build skipped

A production app needs logs, alerts, backups, migration history, ownership of domains and service accounts, and a written handover. Without that layer, the next incident begins with the same search for basic facts.

Our app rescue process delivers a written report within 48 hours after access is complete. It covers the critical path, architecture, payments, auth, data, deployment, and security, then gives you a fixed quote for the agreed repair or rebuild scope.