TL;DR
Every technical founder who sits down with me shows up with the same fear: “I launch in weeks, but I don’t want to rewrite everything three months from now.” The fear is legitimate. It just makes you cut the wrong thing.
The MVP that turns to junk almost never turned to junk for being fast. It turned because it cut the separation (which is cheap to keep and expensive to redo) to keep a feature (which is expensive to build and that almost nobody will use). The MVP that scales does the opposite: it cuts features without mercy and keeps the separation always. It isn’t born a disposable prototype. It’s born as phase 1 of a product, and phase 2 grows on top of it when you cut and kept right.
The numbers anchor the inversion. 42% of startups that die die building something the market didn’t want. In an average product, 64% to 80% of features are rarely or never used. And redoing what came out wrong is the quietest cost: teams rework about 26% of their code before they even ship, and most of that comes from misunderstanding what to build, not from coding fast.
Speed isn’t the enemy of the MVP that scales. Blind scope is.
The MVP doesn’t turn to junk for being fast. It turns for merging everything and keeping the feature.
The image of an MVP the founder carries around is almost always the wrong one: a small version of the whole product. A bit of each thing. Every screen, every feature, just half-baked.
“An MVP is for validating fast. Do the minimum of everything, polish it later.”
That “minimum of everything” is the trap. Minimum doesn’t mean shallow at everything. It means narrow: little, but whole. You pick the one thing the product needs to do well to prove someone wants it, and you do it end to end. The rest isn’t “half-done.” It’s cut.
And here’s the catch the fear of rework hides: separating things is cheap, and merging them back is what costs. A feature is expensive to build and cheap to cut. When you cut architecture to save time, you saved on what was cheap and you’ll pay dearly later. When you cut a feature, you saved on what was expensive and that probably nobody would use.
An MVP that turns to junk cut in the wrong place.
What to cut without mercy
Cutting well is a skill, and it hurts because everything looks essential at the start. It isn’t. Start here:
- Features that don’t validate the thesis. This is the mother of all cuts. If the feature doesn’t help prove someone wants the product, it’s not v1. The 42% that die built something without product-market fit: evidence that there are enough people wanting what you do, at the price you charge. They didn’t die for lack of features. They died from features in the wrong direction.
- The second, third, and fourth feature. In an average product, only 12% of features drive 80% of usage. In the MVP you don’t yet know which slice that is. But you know it’s not all twenty. Bet on one, two at most.
- Scale that doesn’t exist. Cache, queue, sharding, microservice for ten users. Optimizing a load you don’t have is solving an imaginary problem while the real one (someone using it) goes unanswered.
- Configurability. Every “what if the client wants to change this?” becomes a settings panel that doubles the scope. In the MVP, hard-code it. Configurable is a problem for whoever already has clients.
- Polish. Animation, dark mode, a five-step onboarding, an illustrated empty state. All real, all phase 2.
What’s left looks like little. It’s supposed to. If your MVP doesn’t leave you a little embarrassed, you cut too LITTLE.
What to keep always (keeping the separation is cheap; redoing it is what costs)
Cutting features is the easy part once the penny drops. Where I see the founder in a hurry get it wrong is the other side: what you do NOT cut, not even on the tightest deadline. There are few of them, all cheap to get right now and ruinously expensive to redo later.
- The domain model. The names of things and how they connect. Swapping “user” for “account” and “organization” in month six is data migration, a refactor that crosses the whole system, and a production bug. Deciding it in week 1 costs a conversation.
- The divisions between business capabilities. Where payment ends and the order begins. You don’t have to implement both well. You have to know where the line between them sits, so you can later touch one without dismantling the other.
- Identity and who-can-do-what. If the product has more than one kind of user, bolting auth and permissions on later is one of the most expensive refactors there is, because it touches every request.
- A thread of observability. Structured logs and a way to know what broke. It’s not a feature. It’s what lets you sleep.
The number that justifies the stubbornness: teams rework close to 26% of their code before release, and Carnegie Mellon has pointed to the same root cause for decades. More than half of rework comes from a misunderstood requirement, not from badly written code. Expensive rework doesn’t come from you coding fast. It comes from drawing the separation in the wrong place, or from not drawing one at all.
How do I keep a separation for something I don’t even know will scale?
You don’t guess what will scale, nobody does. But you don’t have to: instead of deciding the implementation, you decide where the seams go. Keeping the seam is cheap (a module with a clear name, payment that isn’t shoved into the middle of the order) and behind it you do the simplest, dumbest thing that works today. When the load shows up, if it shows up, you swap what’s behind it without touching whoever depends on it. Phase 2 becomes a part swap, not a restart.
The version of this discipline at the code level (organizing by feature, frontend and backend in the same repository, decisions recorded) we broke down in your codebase is the new prompt, which is what keeps an AI agent productive in your MVP six months later. And the record of why each of those decisions exists lives in the ADRs. This post is the floor above: what to cut and what to keep before the code exists.
The MVP is phase 1, not the prototype (phase 2 is the proof)
There’s a word that gives away an MVP that turned to junk: rewrite. Joel Spolsky called rewriting from scratch “the single worst strategic mistake that any software company can make”, and that was in 2000, long before AI made the rewrite even more tempting and more expensive. The MVP that scales never goes through it. It goes through extensions: each phase adds on top of the previous one, because the previous one left the separation in place.
It’s what we do at Nextside in a Sprint: fixed scope, senior team, a working MVP in 4 weeks that’s born with the right divisions to grow in phases. The hurry stays in the scope, the rigor stays in the separation. And the short deadline isn’t a limitation, it’s the mechanism: it forces the cutting conversation the founder puts off for months.
The MVP that scales is the one you don’t have to rebuild
The difference between the MVP that scales and the one that turns to junk isn’t the stack, the size of the code, or the name of the architecture. It’s two decisions you make before writing the first line: what to cut and what to keep.
Cut the feature, the scale that doesn’t exist, the polish, the “what if.” Keep the domain, the divisions, the identity. Do little, but whole, instead of a lot half-done, and phase 2 becomes an extension of what you already have, not the funeral of what you threw away.
An MVP that scales isn’t the one that got done fastest. It’s the one you won’t have to rebuild.