What is an MVP?
It is the version of your product that can lose a customer's data or their trust. A prototype is never asked to survive that test.
Minimum viable product
MVP
A minimum viable product is the smallest version of a product that real users can rely on to test whether the business works. It has just enough features to solve one problem. But the parts it does have, such as login, data storage, and payments, work the way production software works.
Eric Ries coined the term in The Lean Startup. Build the smallest thing that lets you learn something real from customers, then decide what to build next. The word "viable" is doing the work in that sentence. It does not mean impressive. It means a stranger can use it without you standing next to them.
In scoping calls, we draw the line at three things. Can a user create an account and trust their password is stored properly? Does their data survive a server restart, a bad deploy, or a bug, without silently vanishing? And can a second engineer read the code in six months and add to it, rather than rewrite it? Miss any of the three and what you have is a prototype, however finished it looks on a screen share.
The word gets stretched until it means nothing
Founders under time pressure use "MVP" to mean two different things, and the gap between them is where money gets lost. One meaning is the honest one above. The other is "the cheapest thing that looks done in a demo."
A demo-grade build can pass a pitch meeting and still fail its first real user. Nobody tried to break its login, its payment flow, or its database under concurrent writes. The pitch never asked those questions. A paying customer will, on day one.
The test is not how many features shipped. It is what happens when someone who did not build it uses the product for a real task, with data they actually care about.
- One problemScoped to a single job the user needs done.
- Real authAccounts and passwords handled properly, not stubbed.
- Durable dataSurvives a restart, a bug, a bad deploy.
- Buildable codeA second engineer can extend it without a rewrite.
- Real usersTests the business, not a room full of investors.
Skip the middle two and the result is a prototype, whatever the pitch deck calls it.
An MVP against the things it gets mistaken for
| Criterion | What people build instead | What an MVP actually is |
|---|---|---|
| A prototype | Built to be looked at or clicked through. Data can be fake, and nobody is meant to depend on it. | Built to be used and depended on, by however few people, from day one. |
| A proof of concept | Answers one technical question, then gets thrown away on purpose. | Is the first real version of the product, kept and built on if the test passes. |
| A demo | Optimised for one scripted walkthrough that never touches edge cases. | Optimised to survive whatever an unscripted user actually does with it. |
| A feature-complete v1 | Tries to ship everything the roadmap eventually needs before anyone has used it. | Ships the smallest slice that can prove or disprove the business idea. |
Common questions
01What is the difference between an MVP and a prototype?
A prototype is built to be looked at, not depended on. Its data can be fake and its login can be a stub, because its job is to show what the product will feel like. An MVP is built to be used by real people for a real task. The parts underneath, like authentication and data storage, have to actually work. A prototype answers "does this look right". An MVP answers "does this hold up".
02What is the difference between an MVP and a proof of concept?
A proof of concept answers one technical question, then gets thrown away once it does. An MVP is the first real version of the product, kept and extended if the test succeeds. Teams sometimes need both. A proof of concept settles whether something is technically possible. The MVP, built separately, tests whether customers want it.
03How small can an MVP actually be?
As small as one problem, solved for one type of user, with nothing else attached. The feature count can be tiny. What cannot shrink is the parts a real user's trust depends on: their account, their data, and, if money changes hands, their payment. Cutting those to save time is what turns an MVP into a prototype with a different name.
04Can you build on top of an MVP later, or does it get thrown away?
A properly built MVP is meant to be extended, not replaced. That is the whole point of holding the line on authentication, data storage, and code quality even while the feature set stays small. A prototype, by contrast, is usually rebuilt from scratch once it has done its job, because nothing underneath it was built to last.
