What Is an MVP, Really (and What It Isn't)
What is an MVP? The smallest thing that tests your riskiest assumption with real people. How an MVP differs from a prototype and a v1, and common mistakes.
An MVP (minimum viable product) is the smallest thing that tests the riskiest assumption about your product with real people. It is not a cut-down version of the dream; it is an experiment that leaves you knowing more than you did before.
Ask ten founders “what is an MVP?” and you will get ten answers. Some mean a first version with half the features, some mean a polished Figma mock-up, some mean anything built over a weekend. Here is what actually matters in the definition.
The key word is “assumption”
Every product rests on a handful of assumptions. People have this problem. They know they have it. They will pay to solve it, and roughly this much. You can reach them. The solution is technically possible at all.
Usually one of these is riskier than the rest: if it is wrong, nothing else matters. Your MVP is built around that one. If the big risk is “will anyone pay”, the MVP is a pricing page with a checkout button, not an app with user dashboards. If the big risk is “can a model reliably read these documents”, the MVP is a script that runs a hundred real documents through it, not a landing page.
A quick test: if you cannot say in one sentence which hypothesis your MVP tests and what result would prove it wrong, you do not have an MVP. You have an early version.
What is an MVP compared with a prototype and a v1
These three get mixed up, but they answer different questions.
- A prototype answers “what could this look and feel like?”. People click through it and you show it around, but it delivers no real value. A clickable mock-up, a demo on fake data.
- An MVP answers “do people need this the way we think they do?”. People use it for real, even if behind the scenes it runs on spreadsheets and manual work.
- A v1 answers “can we deliver this reliably?”. It is a product that survives growth, payments, support and security requirements.
Vibe coding blurred the lines. An evening in Lovable or Cursor produces something that looks like a v1. But looks say nothing about which question you have answered. A working app with zero users is just an expensive prototype.
How small should an MVP be?
Smaller than you think. A useful exercise: list everything you want to build and ask of each item whether it changes the answer to your main question. If it does not, cross it out.
Login with five social providers, dark mode, notification settings, an admin panel: these almost never test a hypothesis. Sometimes the MVP needs no code at all. A form, a spreadsheet and you answering by hand is called a concierge MVP, and it is more honest than many apps.
The word “viable” still means something, though. An MVP has to solve the problem well enough that someone wants to come back. If the thing is unusable, a user walking away tells you nothing about your hypothesis, only that the product was raw.
Common MVP mistakes
- Building what is easy instead of what is risky. Interfaces are fun to build, so they get built. The real risk, say, sales, stays untested.
- Not deciding upfront what success looks like. Without a threshold, any result can be read as “pretty promising”. Write it down before launch: how many people, doing what, within what time.
- Showing it only to friends. Friends are polite. They like everything.
- Treating the MVP as a foundation. Code written to test a hypothesis often is not fit for growth. That is fine; it had a different job. The problem is forgetting that and stacking a v1 on top without a second look.
- Dragging it out. An MVP that takes six months to build is testing a different market, and your patience.
What to do after the MVP
If the hypothesis held, move on to the next riskiest one and, in parallel, decide which parts of what you built are worth keeping. If it did not hold, that is a result too, and a cheap one. Change the hypothesis, not the button colour.
Moving to a v1 almost always means revisiting the code: what runs on manual workarounds, where access checks are missing, what will break at a hundred users instead of ten. Better to do that deliberately, before your users find the weak spots for you.
In short
- An MVP is the smallest thing that tests your riskiest assumption with real people.
- A prototype shows what a product could look like, an MVP tests whether it is needed, a v1 delivers it reliably.
- Before launch, write down the hypothesis and the threshold that confirms or kills it.
- An MVP can often be built with little or no code.
- MVP code does not have to become the foundation of your v1, and that is normal.
SUBXCAT helps turn a validated MVP into a product that holds up under real users.