Keep building on your MVP unless one of three things is true: the stack cannot support a feature customers are paying for, the cost of every change is rising month on month because of how it was built, or the platform it runs on is going away. A rebuild costs $40,000 to $150,000 (€35,000 to €130,000, £30,000 to £110,000) and three to six months in which the product stands still, and most teams that rebuild on gut feeling regret it. The right default is incremental replacement: fix the worst part, keep the rest, and let the product fund the work.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Somewhere between the first thousand users and the first serious funding round, a developer will tell you the MVP needs to be rebuilt. Sometimes they are right. More often they are describing code they did not write and would have written differently. This post gives you a way to tell the two apart, because the wrong answer in either direction is expensive.
Why does the rebuild question come up?
An MVP is built to learn, so it carries shortcuts. Some were deliberate: a manual process instead of an integration, one database table where there should be three, no automated tests on the admin panel. Some were accidental: a developer who left, a library that was fashionable, a feature bolted on in a week to close a deal. After launch the product grows past the shortcuts, and every new feature seems to touch something fragile. That is normal. It is technical debt doing exactly what the word implies, and the question is whether to keep paying interest or refinance.
What are the three signals that justify a rebuild?
| Signal | How to measure it | What it looks like |
|---|---|---|
| 1. A paid-for feature is impossible | Customers are paying or have signed for something the current architecture cannot deliver at any reasonable cost | Real-time collaboration on a system built for single users. Multi-tenancy on a system with one tenant hard-coded everywhere. |
| 2. Change cost is rising month on month | Compare the days a typical small feature took three months ago, six months ago, and now | A new form field used to take a day and now takes a week, and the trend is steady, not a one-off. |
| 3. The platform is ending | A vendor end-of-life date, a framework with no security updates, a no-code tool you have outgrown | The no-code platform caps you at a record limit you will hit in six months. |
One signal is a reason to plan. Two is a reason to act. None is a reason to keep building and address the pain points one at a time.
What is not a reason to rebuild?
- "The code is messy." All code that has shipped is messy. Mess is a cost only where you change things often.
- "We would not choose this stack today." Nobody would choose last year's stack today. The stack you have works, and the one you would choose will be last year's stack next year.
- "It does not scale." Ask: to what? Most MVPs are nowhere near the limits of their stack. Make the developer name the number of users at which it breaks and the evidence for that number.
- "A new developer wants to." Every engineer prefers code they wrote. That preference is not a business case.
- "The investors expect a proper version." Investors expect retention and revenue. A rebuild delays both.
What does a rebuild actually cost?
The quote is the smaller part. A rebuild of a product with a year of features costs $40,000 to $150,000 (€35,000 to €130,000, £30,000 to £110,000) in engineering, since every feature that exists has to be rebuilt before anything new can ship. The larger part is time: three to six months in which the product does not improve, competitors do, and the team is split between keeping the old one alive and building the new one. Then there is migration, meaning moving every user and every record without losing anything, which is its own project. Teams routinely budget for the first cost and discover the other two.
What is the alternative to a rebuild?
Incremental replacement, sometimes called the strangler pattern. Identify the one part of the system that is causing most of the pain, build its replacement alongside the old version, switch traffic over, delete the old part. Repeat with the next worst part. The product keeps shipping features throughout, each step is small enough to reverse, and the parts that were fine are never touched. Our post on software modernisation without the big bang describes the same approach for larger systems, and it works at MVP scale too.
- List the parts of the system by how often they change and how painful each change is.
- Take the top item. Define a clean boundary around it.
- Build the replacement behind that boundary, with tests.
- Switch over, watch for a week, delete the old code.
- Reassess the list. Often the second item has stopped hurting once the first is gone.
When is a full rebuild genuinely right?
When the MVP was built on a no-code platform and the product has outgrown it, since there is nothing to replace incrementally. When the original was built so quickly that there are no boundaries to work within, and everything touches everything. When the business has changed so much that the product being rebuilt is a different product. And when signals one and three above both hold. In those cases, rebuild, but scope the rebuild like an MVP: ship the core journey first on the new system, migrate those users, and add the rest in order of use.
Rebuild if
- Paying customers need something the architecture cannot do.
- The platform or framework is ending and there is no upgrade path.
- It was built on no-code and the limits are months away.
Keep building if
- The complaints are about style, not about measured change cost.
- Nobody can name the number of users at which it breaks.
- The pain is concentrated in one or two parts you can replace one at a time.
How 7L handles the question
When a founder brings us an MVP another team built, we start with a short technical review: the three signals above, measured rather than felt. The recommendation is usually incremental, because that is what keeps the product shipping, and we say so even when a rebuild would be a bigger contract. When a rebuild is right, we scope it as a new MVP on the existing data. If you are being told to rebuild and want a second opinion, send us what you have.
Frequently asked questions
How do I know if my developer is right that the MVP needs a rebuild?
Ask for the three signals: a feature customers want that the architecture cannot deliver, a measured rise in the time a small change takes, or a platform end-of-life. Ask for the numbers. A good developer will have them or will go and get them. A vague answer means the case is preference, not evidence.
Can I rebuild an MVP while it is still running?
Yes, and you should. The old product keeps serving users and earning while the replacement is built behind it. The switch is done part by part or, for a full rebuild, user group by user group. A rebuild that takes the product offline is a planning failure.
How long does an MVP rebuild take?
Three to six months for a product with a year of features, because every existing feature has to exist again before anything new ships. Incremental replacement spreads that over the same period without pausing new features, which is why we prefer it.
Does a rebuild mean changing the tech stack?
Not necessarily. Many rebuilds keep the stack and fix the structure. Changing the stack adds learning cost and risk, and is justified only when the stack itself is the problem, such as a framework without updates or a no-code platform at its limits.
Will investors see a rebuild as a red flag?
They see the result. A rebuild that was justified and delivered without stalling growth is a sign of a mature team. A rebuild undertaken on preference that stalled the product for six months is the red flag. Our post on what investors want to see in your tech covers what they actually check.