A version two rewrite almost always starts in the scoping conversation for version one, not in the code. When a team skips a specific decision early, they build features on top of an assumption that doesn’t hold, and by the time real customers show up, the foundation needs replacing rather than extending.
The three decisions that decide the outcome
Three choices made before a single feature gets built determine whether an MVP grows into version two or gets thrown out: how the data is modeled, how identity and permissions work, and where the system’s boundaries sit with outside services. Everything else, including which features ship first, is comparatively cheap to change once the product is live.
These three are expensive to reverse because other decisions get stacked on top of them within weeks. A data model built around a single user per account, for instance, looks fine until a customer asks for a teammate to log in too. Fixing that later doesn’t mean adding a field. It usually means touching every query that assumed one user per row.
Why a feature list is the wrong place to start
Founders usually arrive at scoping with a list of features they want built, but a list ranks work by how visible it is to a user rather than by how expensive it is to change later. A login screen and a payment integration look similar sitting next to each other on a roadmap. Underneath, one takes an afternoon to rebuild and the other takes a month.
A scope built entirely from a feature list tends to reward whatever demos well. Whatever demos well is not the same thing as whatever will still be standing in six months.
What actually happens in a good scoping session
A useful scoping session spends less time deciding what to build and more time deciding what to defer, on purpose, in writing. For each feature under discussion, the team works through three questions: does it touch the core data model, does it lock in a decision that’s expensive to reverse, and can this be faked with a manual process for the first small group of users.
That third question does most of the work. A waitlist can be a spreadsheet and an email before it’s a feature. A recommendation engine can be one person picking five products by hand each week. Neither of those shortcuts costs anything to unwind once the automated version is actually needed.
The one-page document that prevents the rewrite
The output of a good scoping process is short: one page listing the core data entities, the identity model, the external integrations, and an explicit list of what’s deliberately left out of version one. Anything not on that page is assumed unbuilt, which forces disagreements about scope to happen before code exists instead of after.
Kody Doherty, who works as a fractional CTO for early-stage teams, lays out this approach in Scoping an MVP so version two is not a rewrite, and argues the document matters less for what it includes than for what it forces a team to say out loud before anyone writes a line of code.
What cutting scope actually means
Cutting scope on an MVP rarely means shipping less product. Usually it means replacing an automated feature with a manual process that only the founding team ever sees. A support inbox stands in for a chatbot. A shared calendar stands in for a scheduling engine. The customer experience stays intact while the hard engineering waits until there’s evidence it’s needed.
This is where a lot of scoping conversations quietly fail. Teams agree to defer a feature, then build the plumbing for it anyway, out of habit or discomfort with leaving something unfinished. That plumbing is the rewrite risk, sitting there unused, coupled to code that will need to change around it later.
Where teams get this wrong even when they know better
Even experienced teams underestimate how much a rewrite will cost, because a codebase can look fine for months before the cracks show. A system built on a single wrong assumption about the data model keeps working right up until a second assumption gets added on top, like multiple currencies, or user roles, or a second workspace per account. For a lot of products, that second assumption doesn’t arrive until well after version one already has paying customers.
By then the fix isn’t a patch. It’s a rebuild dressed up as a feature request, and it costs more than the original scoping conversation ever would have.
