Eric Ries put the minimum viable product into every founder's vocabulary with The Lean Startup in 2011, defining it as the version of a product that lets a team collect the most validated learning about customers for the least effort. The term itself is older — it's usually credited to Frank Robinson around 2001, and Steve Blank carried it into Silicon Valley orthodoxy. Read that original definition again and notice what it is actually about: learning. Not cheapness. Not speed. Not a half-built thing you apologize for in the demo. Fifteen years later, the industry has kept the acronym and thrown away the meaning, and the result is a word that now mostly functions as cover for shipping garbage.
Ask ten founders what an MVP is and nine will describe a quality level: the cheap version, the rushed version, the one with the rough edges you'll sand down 'after we raise.' That is the single most expensive misreading in modern product work, and it starts with which word people lean on.
The industry amputated the word 'viable'
'Minimum viable product' is three words. In practice, teams hear one of them — minimum — and treat the other two as decoration. 'Viable' is the load-bearing word, and it's the one that gets quietly dropped. Viable means it works. Viable means a real human can complete the one job the product exists to do, end to end, without a member of your team sitting next to them whispering workarounds. A product that demos well in a controlled room and collapses the moment a stranger touches it is not minimal. It's just not viable.
What most people actually build and call an MVP is a minimum demoable product — an MDP. It survives the happy path, looks fine in a slide, and dies on contact with a second user, a slow network, or a payment that fails halfway through. The distinction matters because an MDP teaches you nothing true. You wanted validated learning; you got a magic trick you performed on yourself.
Minimum is a scope decision. Viable is a quality decision. They are not the same axis.
Here is the part the consensus take refuses to separate. 'Minimum' is a constraint on scope — how many things the product does. 'Viable' is a constraint on quality — how well it does them. These are two different dials, and the entire art of an MVP is turning one all the way down while leaving the other alone.
You cut features. You do not cut craft. You ruthlessly remove jobs the product won't do yet — the settings page, the third onboarding flow, the analytics dashboard nobody asked for — and then you make the one remaining job genuinely solid. The 'minimum' is supposed to hurt: it should leave out things you're proud of. What it is never licensed to do is leave the surviving feature flaky, insecure, or confusing. 'We'll fix the bugs later' is not minimalism. It's deferred failure with better branding.
This is why the cheapest-possible-build interpretation is so destructive. It collapses two dials into one and turns 'do fewer things' into 'do things badly.' Those are opposite instructions. The first is discipline; the second is debt you'll service for years.
Finding the real minimum is harder than building the maximum
The dirty secret is that arriving at a true minimum is more intellectually demanding than just building everything someone asked for. Anyone can write a 40-feature backlog. Deciding which single feature earns the product the right to exist — and being able to defend the cut — is the actual work. Most teams skip it because it's uncomfortable, then call the resulting pile of half-features an MVP.
We've inherited enough stalled builds to recognize the pattern on sight. On one rescue — a project called Meal4U where the previous team had failed to deliver — we spent a full week doing nothing but deconstructing scope, re-estimating the build something like ten times, cutting 30 to 50 percent on each pass until we found the smallest thing that could actually ship and stand on its own. That week of subtraction was the product work. The code came after. If your MVP planning didn't involve at least one argument about what to remove, you didn't plan an MVP — you planned a v1 and shrank the timeline.
Viable means someone comes back
The honest test of viability isn't whether the product compiles or whether the investor nodded. It's whether a real user does the thing again. Returns. Pays. Tells someone. That's the validated learning the original definition was reaching for, and it only registers if the experience was good enough to be worth repeating. A broken first impression doesn't generate a signal you can trust — it generates a user who left, and you can't tell whether they left because the idea was wrong or because the build was bad. You spent your one experiment and learned nothing.
This is the case against the 'ship it broken, iterate fast' religion. Iteration only works on a foundation that gave you a clean reading. Ship something non-viable and your iteration loop is just you flailing against noise, adjusting features when the real problem was that nothing worked well enough to evaluate in the first place.
The 'MVP factory' and why we refuse to be one
There's an entire market segment built on selling the corrupted definition: cheap, fast, throwaway MVPs produced like burgers. We deliberately don't play there — we're a boutique studio, not an MVP factory — because that model bakes the misunderstanding into the contract. You're sold 'minimum' as a synonym for 'disposable,' and then six months later, when the idea actually shows signs of life, you discover the thing can't be extended and has to be rebuilt. The cheap MVP wasn't cheap. It was a down payment on a second project.
A real minimum viable product is built to be the seed of the real product, not a stunt double for it. That's the difference between scoping down and skimping. The architecture underneath the one feature you shipped should be the architecture the next ten features grow from. When we extended a client's one-page concept into a 40-page specification before writing the platform, or committed to a 90-day go-live on a marketplace build, the point was never to maximize features on day one — it was to make day one's small surface honest and the path past it real.
So what is an MVP in software — plainly
An MVP is the smallest product that does one valuable thing well enough that a real user would choose to use it again, built on foundations that can carry what comes next. 'Minimum' is the discipline of doing fewer things. 'Viable' is the non-negotiable that the few things you do are actually good. 'Product' means it stands on its own without you in the room. Drop any of the three and you don't have a smaller version of your idea — you have a more expensive way of learning nothing.
The conventional wisdom treats MVP as permission to be sloppy in exchange for being fast. The correct reading is almost the opposite: it's permission to be small in exchange for being disciplined. If your MVP plan is mostly about what you're allowed to leave broken, you've misread the term. The good news is the fix is free — stop pointing the quality dial at the floor, point the scope dial there instead, and build the one thing that's left like you mean it.
Last updated July 10, 2026