When should you rebuild an MVP?

Define the trigger as a product constraint

Write the user or operating outcome the current system cannot reliably support. Attach observable evidence such as incident records, failed changes, measured limits, unsupported dependencies, inaccessible critical paths or an inability to recover. Separate current pain from predicted future scale. A hypothetical volume or disliked architecture is a weak trigger unless it maps to a tested threshold and credible near-term need.

Stop a rebuild proposal that lacks a maintained product goal, data owner or decision owner. Rebuilding implementation cannot repair an unclear value proposition, absent users or unresolved operating responsibility. If evidence says the product direction is unvalidated, use discovery or a smaller experiment rather than translating every uncertainty into a new technical platform.

Inventory what must survive the change

Map critical journeys, business rules, data sets, integrations, identities, permissions, analytics, compliance records, domains, stores, deployment and support. Record intentional behavior separately from accidental behavior that users may still depend on. Identify source-of-truth systems, data retention needs and provider constraints. Do not begin from the screen list alone.

Establish a production baseline: failure frequency, recovery effort, release lead time, testability, maintainership and measured performance where relevant. Note evidence quality and gaps. The baseline lets the team evaluate whether a repair or replacement improves the named constraint and prevents a visually cleaner rewrite from being called a success while reliability or operability worsens.

Test repair, containment and replacement paths

Run a bounded technical investigation on the hardest constraint. Options may include upgrading one dependency, placing an API boundary around a fragile component, adding characterization tests, correcting the data model or replacing one vertical slice. Evaluate how much risk can be removed without migrating the whole product. Preserve a fallback while the new path is unproven.

If a rebuild remains justified, sequence it around user outcomes and data movement rather than recreating every old screen. Define coexistence, migration validation, rollback, support and decommission conditions. Avoid an indefinite parallel system by assigning a decision date to each component. A large one-time cutover needs stronger recovery evidence than a gradual replacement.

Accept the new path against the original constraint

Use the same critical journeys and measurable boundaries for old and new paths. Test data completeness, permissions, error handling, performance where consequential, accessibility, observability, deployment and recovery. Record which defects are fixed, which remain and which behaviors changed deliberately. Completion of new code is not acceptance if migration or operation is still unproved.

Define acceptance as observable evidence. Examples include a tested user journey, an approved build, reproducible checks, an incident runbook and a verified handover. None of those proves retention, revenue or product-market fit. Keep delivery proof, external provider approval and business results as separate claims.

Handover, observe and retire deliberately

Place new repositories, infrastructure and provider access under organisational ownership and document how to release and recover. Observe the new path through a defined period or traffic boundary before retiring the old one. Preserve required data and audit evidence, remove obsolete access safely and record the retirement decision. Do not claim adoption or commercial improvement from a technically successful migration alone.

Keep source control, domains, stores, analytics, cloud organisations and production credentials under explicit organisational ownership. Grant scoped, revocable access and rehearse handover before the final invoice. The supplier label matters less than whether another authorised person can inspect, deploy, recover and continue the product.

Decision criteria

Use the same questions for every option before choosing.