Rescue or rebuild an AI-built MVP

What changes when real users arrive

The MVP showed that people will use the product. That was its job. Once real users depend on it, the question changes. The product may hold other people’s accounts, data, and payments, and a break may have consequences outside the demo.

Common signs are familiar: fixes break something else, nobody can explain parts of the code, a customer or investor asks a security question, or the builder tool’s limits block a feature.

AI-written code is not the problem by itself. The risk is code nobody has reviewed, tested, or taken responsibility for. The right first move is a review that names the areas to keep, harden, replace, or rebuild.

That review also protects the money already spent. It keeps useful product learning from being thrown away, while still making room to replace unsafe parts. A rebuild quote written before the review can miss both.

Start with a health review

Begin with a product and technology audit before anyone promises support, a rebuild, or a fixed result. The review should inspect the product as it is, including the way it is deployed and the risks users already depend on.

Check where the code lives. It should be in a repository you control, with history, and deployable without the tool that generated it.

Check secrets and credentials. Look for keys in code or the browser, and name who holds admin access, including former contractors.

Check who can see whose data. Access should be enforced on the server and in the database, not only hidden in the interface.

Check money paths. Payments, refunds, and payment notifications should behave safely when a notification repeats or arrives out of order.

Check the data model. It should describe how the business works now, not only how the first demo was imagined.

Check tests around the flows users depend on: sign-up, sign-in, the core action, and billing.

Check release safety. Backups should have been restored in a test, rollback should exist, and monitoring should tell a named person when something fails.

Check dependencies. Unknown packages, outdated services, and builder-platform limits belong in the review record.

The output is a written finding per area: keep, harden, replace, or accept with the risk recorded. It also sets the order of work. The review informs scope. It does not promise coverage or a fixed result by itself.

The finding should be specific enough to guide a next step. “Replace authorization” is useful. “The app is messy” is not. The review should leave the founder with a map of risk, not a slogan.

Review finding Usual call

Bounded problems

Review finding: Exposed secrets, missing server-side checks, fragile payment handling, no tests

Usual call: Harden

One untrusted layer

Review finding: Authorization, data access, or payment handling can’t be trusted, but the rest holds

Usual call: Replace that layer

Wrong foundation

Review finding: Data model, platform, or structural security wrong

Usual call: Rebuild, with the current product as the reference

No operating owner

Review finding: Nobody is named to run the product after the fixes

Usual call: Not ready for more users, whatever the code state

A finding should point to a specific area, not to the tool that wrote the code.

Rescue, replace a layer, or rebuild

Most products end up with a mix, decided per area.

Harden what you have Replace a layer Rebuild

Scope

Harden what you have: Bounded fixes to security, money paths, tests, and release safety.

Replace a layer: One layer, such as authorization, data, or payments, replaced behind the same behavior.

Rebuild: A new foundation, using the current product as the reference.

Responsibility

Harden what you have: Fixes are accepted against the flows users depend on.

Replace a layer: Existing users keep agreed behavior, with migration checked before data moves.

Rebuild: The new build passes acceptance examples taken from the current product before users move.

Access

Harden what you have: Repository, hosting, database, and payment settings, with credentials rotated.

Replace a layer: The same, plus a safe environment to test the migration.

Rebuild: Read access to the current product and data to plan the move.

Continuity

Harden what you have: Users keep the product throughout.

Replace a layer: Users keep the product, with a rollback plan for each switch.

Rebuild: The old product runs until the new one is accepted and data has moved.

Fit

Harden what you have: The data model fits the business and problems are bounded.

Replace a layer: One layer can’t be trusted, but the rest holds.

Rebuild: The data model, platform, or product direction is wrong at the foundation.

Decide per area. Most products need some of each.

When hardening is enough

Hardening is enough when problems are bounded and the foundation still fits. Exposed secrets can be rotated. Missing server-side checks can be added. Fragile payment handling can be made safe to repeat. Tests and monitoring can be added around the flows people use.

This path is not a patch over a bad base. It is the right call when the data model describes the business, the product direction still holds, and the risky parts can be fixed without changing the user-facing behavior.

Hardening should still end with evidence. Existing users should keep the behavior they rely on, and the team should know who responds when the next incident or dependency update appears.

This path can be the least disruptive when users are already active. It lets the team remove the riskiest gaps while preserving the workflow that proved the product was worth taking seriously.

When to replace one layer

Replace a layer when one part cannot be trusted but the rest of the product holds. The layer may be authorization, the data access path, payment handling, or a dependency on the builder environment.

The replacement should sit behind the same user-facing behavior. Agree acceptance examples for what existing users must keep. Check the data migration and rollback before switching data. The aim is to remove the layer that makes change unsafe while the rest of the product keeps working.

Layer replacement needs a careful boundary. If the team replaces data access, it should know which screens, jobs, and reports depend on that data. If it replaces payment handling, it should know which status changes users and operators expect.

For older systems where the same pattern becomes a long staged program, see how to refactor, rewrite, or wrap an older system.

When a rebuild is the honest answer

A rebuild is justified when the foundation is wrong. The data model may not describe how the business works now. The product may have changed direction. The code may be unable to leave the platform it was built on. Security problems may be built into the structure rather than isolated in one layer.

A credible rebuild recommendation points at review findings, not at the fact that AI helped write the code. It should say what cannot be safely retained and why.

The MVP is not wasted. It shows how real users move through the product today. Its screens, flows, and edge cases can become acceptance examples for the new build.

Run the old product until the new one passes those examples, then plan how data and users move across.

Fix the money and data paths first

Start by stopping exposure. Rotate credentials that should not be public, remove access that should not exist, and settle control of accounts before adding features.

Then fix data access and money paths. Enforce who sees what on the server and in the database. Make payment handling safe when a notification repeats, arrives late, or needs a correction.

Next, add tests around the flows users depend on, so later changes can be checked. Then add release safety: restored backups, rollback, monitoring, and a named person who responds.

Only after those are visible should the team refactor, replace, or rebuild in the order the review set.

Who owns the product after the fixes

A fixed product still needs someone to watch it, respond to incidents, apply updates, and decide on changes. If nobody owns those decisions, the product is not ready for more users.

Your own team can own it if it can release, recover, and make product decisions. Managed support can fit agreed care of a live system. A Forward Deployed Engineer (FDE) can fit when the next step is new work that needs close access to users and systems. When UCS did the fixes, Reverse FDE can prepare your people to practice before taking over.

If a different team did the fixes, agree what a warranty covers and what managed support adds before day one. If a former contractor or agency still holds accounts, repositories, or admin access, settle who controls the code and accounts first.

Keep using AI coding tools, with review

The tools can stay in the workflow. What changes is review, tests, and ownership.

Engineers should review what the tools produce. Tests should gate releases. Someone should own architecture and security decisions. To make this a practice across the engineering organization, see how to set up AI coding agents across your team.

Whatever wrote the code, each change should be understood, reviewed, released, and operated by people who own it.

A decision checklist

Answer these before you ask anyone to quote.

Can you deploy the code without the tool that generated it?

Check whether the code is in a repository you control, with history, environment configuration, and a repeatable deployment path. If the product depends on the original generation tool to deploy, treat that as a review finding before adding features or promising support. A product you cannot deploy is hard to fix safely.

Who can reach admin access and credentials today?

Name everyone with admin access to the repository, hosting, database, payments, domain, and monitoring. Remove access that no longer belongs there, rotate exposed credentials, and record who can approve future access. Accounts left behind by former contractors are a business risk when nobody can see them. Do this before new work starts or new vendors are added.

Where is each user’s access to data enforced?

Do not rely on hiding buttons or screens. Access rules should be enforced on the server and in the database where the data is read or changed. Test attempts to reach another user’s records, including records reached through direct calls rather than the interface. Treat every unclear rule as a review finding.

What happens if a payment notification arrives twice?

Payment paths should be safe when messages repeat, arrive out of order, or are corrected. The product should not create duplicate charges, mark the wrong account, or lose the event. Write the expected behavior down, then test it before more users rely on billing. Money paths should be boring before growth.

Does the data model match how the business works now?

Look at the records the product stores and compare them with the real workflow. If people use workarounds because the model cannot represent customers, orders, permissions, or states, hardening may not be enough. A wrong data model is often a foundation problem. It can make every feature harder and every report less trustworthy.

Which behavior must existing users keep?

Collect acceptance examples from real flows before changing layers. Include ordinary use, edge cases, and the behavior users already rely on. These examples protect the parts of the MVP that real users depend on and keep a rebuild from drifting away from what people actually do. They also help judge layer replacements.

Who will run the product after the fixes?

Name the owner before adding more users. The owner may be your team, managed support, or a later transfer, but it cannot be assumed. A fixed product still needs updates, incident response, access decisions, and a way to approve changes. If nobody owns those, the rescue is incomplete and the next break will reopen the same problem.

When another engagement fits better

If the product is not live yet and the idea is still being tested, keep building inside product engineering until the core workflow is clearer.

If the MVP includes an AI feature whose answers you cannot judge, read why AI proofs of concept stall before treating it as production. If nobody on your side can make the keep or replace calls, a fractional CTO may need to own the decision.

Who to bring in, and in what order

When real users, money, or private data depend on the product, stop adding features until you know what is there. Then bring help in this order:

• Independent review. It answers what is actually there, what users rely on, and which risks matter.
• Hardening help. It answers whether security, data access, backups, and deploys are safe enough before more users arrive.
• A fractional CTO. It answers the open decisions: what to keep, rebuild, or buy, and what risk to accept.
• A first engineer. It answers who does steady execution every day once the path is clear.

The first two steps come first because a decision or a hire is only as good as what you know about the product. After that, use this test: is the open problem a decision or execution? A decision calls for a fractional CTO. Steady daily execution calls for an engineer. If the decisions will keep coming, compare fractional and full-time CTOs.

Bring the product and its users

UCS reviews and fixes products built mostly with AI coding tools.

Bring a short description of what users do, how the product was built, where the code and data live, known incidents, who holds admin access, and any payment provider involved. Name who decides scope and who approves access.

Do not send credentials, customer records, production database exports, or repository dumps in the first message.

You can also email hello@ucs.tech with a short description of the product, its users, and the current risk.

Questions before we start

Should we fix or rebuild our AI-built MVP?

Review it first, then decide area by area. Keep and harden what works, replace the layers you can’t trust, and rebuild only when the data model, the platform, or the security design is wrong at the foundation. Name who will run the product afterward.

Can an app built with AI coding tools go to production?

Yes, once someone has reviewed it and taken responsibility for it. Check access to data on the server and in the database, money paths, tests on the flows users depend on, and whether you can restore data and roll back. The tool that wrote the code matters less than whether anyone owns it.

What should a review of an AI-built codebase produce?

A written finding for each area, such as code location, credentials, data access, money paths, the data model, tests, and release safety. Each finding should say keep, harden, replace, or accept with the risk recorded, plus the order of work. The review informs the scope. It doesn’t promise a result by itself.

Does rebuilding waste what we spent on the MVP?

No. A rebuild keeps what the MVP taught you about how real users work. Its flows can become the acceptance examples for the new build, and the old product can keep running until the new one passes them.

Can we keep using AI coding tools after the fixes?

Yes. Keep human review of what the tools produce, tests that gate releases, and a named owner for architecture and security decisions.

Who should run the product after it is fixed?

Your own team if it can now operate it, or managed support for agreed care of a live system. If your people should take over later, plan practice before responsibility moves. Agree this before you add more users.