2026-10-25 · 6 min read

Repair vs Rebuild Your MVP: A Decision Guide

From Plixy · About Arman Khan, founder ↗

Repair a stalled MVP when you can reproduce its failure, identify a bounded cause and verify a fix without destabilizing the working product. Consider replacing one workflow when the problem is concentrated behind a clear boundary. A full rebuild needs stronger evidence: the existing foundation prevents essential changes, and a migration plan is safer than continued repair.

Code that looks unfamiliar, was generated with AI or uses a different framework is not enough evidence for a rewrite. The decision should account for working behavior, real data and the cost of keeping users supported during the change.

Compare all three options

Collect this evidence before accepting a rewrite quote

1. Reproduce the most important failing journey with synthetic accounts and record the exact deployed version.
2. Build from a clean checkout and list the services, credentials and configuration it requires, without copying secret values into the report.
3. Trace the failure across the browser, server and database. Separate what is observed from the suspected cause.
4. Identify the user data, permissions, payments and external integrations that must survive a change.
5. Define what successful recovery looks like and how the release could be reversed. Ask for uncertainty and exclusions in each estimate.

A useful diagnosis can end with ‘repair this one path’ or ‘we still need access to decide.’ That is more credible than declaring every inherited app a rebuild. Access limits belong in the recommendation: a public URL alone cannot establish database rules, backups or internal implementation quality.

Worked example: a failing booking flow

A booking app shows duplicate reservations when the user retries after a connection loss. The account area and calendar already work. Before replacing the app, reproduce the retry in an authorized test environment and inspect how reservation creation handles repeated requests.

If the fault is confined to duplicate creation and a server-side invariant can prevent it, a repair is the first candidate: define the uniqueness rule, preserve legitimate repeat bookings and verify both paths. If several booking paths bypass the same rules, replacing that workflow behind one tested boundary may be easier to reason about. Neither observation alone proves that the entire app must be rewritten.

A rebuild becomes a serious candidate if investigation finds essential requirements cannot be met safely through bounded changes. The proposal must still preserve account identity, existing reservations and operational access. Recreating screens does not solve those migration obligations.

If the prototype was built with Lovable

Lovable documents exporting and syncing source with GitHub and offers different hosting and ownership paths. Exporting source creates an inspectable starting point; it does not automatically move every backend service, user record, secret or integration. Inventory those separately before deciding to repair, migrate or rebuild.

Check the launch path before inviting real users →

A replacement needs an exit plan

An incremental replacement can put a new implementation behind an existing boundary and move traffic gradually. Martin Fowler describes this approach through the Strangler Fig pattern. It is useful when boundaries can be separated; it is not a requirement to turn a small MVP into microservices.

• ▸Map old records and identifiers to the replacement; rehearse the migration on authorized copies before cutover.
• ▸Check record counts and important relationships, then exercise the user journeys that depend on them.
• ▸Define who can write data during the transition and how incompatible writes would affect rollback.
• ▸Agree cutover checks, support ownership and the point at which the old path can be retired.

Ask for a decision, not a sales label

The recommendation should name the observed problem, preferred option, alternatives rejected, access limits and next verifiable step. Compare the same recovery outcome across proposals, including migration and support. Until there is evidence, ‘repair or rebuild’ is an open investigation rather than a fixed-price conclusion.

For a stalled product, Plixy’s app rescue service starts with the existing app and its failure. For a bounded security-focused first look, see the free MVP review and its access limits.