The MVP came from a world where every line of code cost money, every feature took a sprint, and validating a hypothesis required months of engineering. The right move was to strip the idea to its skeleton, ship a deliberately-incomplete version, and let the market tell you whether to invest in the rest. The thinking was sound. The math has changed.
The economics behind the term collapsed.
A version of what we used to call an MVP took three to six months of a small team's time. The same scope today, in our hands, takes a week. Not the polished marketing-page version — the actual working software, end-to-end, deployable. The question what would it take to prove this gets a different answer when the proof is cheaper than the meeting that authorized it.
When the cost of building the real thing collapses, "minimum viable" loses its meaning. There's no longer a long tail of features you're deliberately deferring. There's the scope you wanted, and there's the scope you'd cut for taste. The distinction between "the rough version" and "the real version" is mostly gone.
We see this shift inside engagements all the time. A client asks for an MVP. We start scoping the cut-down version — what to leave out, what to fake, what to defer. Halfway through, we realize the full version takes about the same time. There's no "save it for v2" tier left. The thing either belongs in the first release or it shouldn't be in the product at all.
The vocabulary distorts the decision.
MVP-thinking, applied inside that new reality, distorts decisions. It encourages teams to ship the unconvincing version of an idea — the prototype, the proof of concept — and then read its tepid reception as a signal about the idea itself. It isn't. It's a signal about the unconvincing version. Users are reacting to what they were shown, and what they were shown was a sketch.
A better frame: ship the smallest scope you'd be proud of. Not the smallest scope you can technically deploy. The economic constraint that produced "minimum viable" is gone in most of the contexts where we used to apply it.
Where it still applies.
MVP-thinking still makes sense at the edges of capability — where you genuinely don't know whether the underlying tech will hold. New AI behaviors, novel hardware, untested integrations. There, the smallest possible proof is the right move, because the unknown is real.
But most product work isn't there. Most product work is "we know how to build this, what's the right scope." For that, the better word is just version one. Not minimum. Not viable. The actual thing, shipped early.
The MVP didn't die because the philosophy was wrong. It died because the constraint it was solving for went away. We just kept using the word.