MVP vs prototype vs proof of concept: what you actually need
Three terms founders mix up. Here is what each one is for, when to use it, and how to pick the right one for your stage.
"We need an MVP." It is the most common sentence we hear from founders, and about half the time, an MVP is not what they need yet. Here are the three terms, in plain language.
The short version
| Proof of concept (PoC) | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Can this be built? | Will people understand and want it? | Will people use it and pay for it? |
| Who sees it | You and your engineers | Test users, investors | Real customers |
| Is it real software? | A throwaway experiment | Usually not. Clickable mock-ups | Yes, but small |
| Typical effort | Days | Days to a couple of weeks | Weeks to a few months |
Proof of concept: can it be built?
A PoC tests technical feasibility. You use it when the risk is in the technology, for example "can we get accurate results from this data?" or "can this integrate with that system?"
It is not a product and nobody outside your team needs to see it. If the technology is well understood, skip the PoC.
Prototype: will people get it?
A prototype tests the idea and the experience. It is often a clickable design in a tool like Figma, with no real backend. You put it in front of potential users and watch what they do.
Use a prototype when you are not yet sure about the flow, the features, or whether people understand the value. It is the cheapest place to be wrong.
MVP: will people use it and pay?
A minimum viable product is real, working software with just enough features to deliver the core value to early customers, so you can learn from real behaviour.
The hard word is minimum. A good MVP does one job well, for one type of user. Everything else waits.
How to choose
Ask what your biggest risk is right now:
- "I'm not sure it can be built." Start with a proof of concept.
- "I'm not sure anyone wants it, or that they'd understand it." Start with research and a prototype.
- "I know the problem is real. I need to see if people use and pay for my solution." Build the MVP.
Often the right order is: validate the problem, prototype the experience, then build the MVP.
Common MVP mistakes
- Too many features. If you cannot describe the core job in one sentence, the scope is too big.
- Skipping the customer conversations. Software does not replace talking to users.
- Building for scale. Early on, simple and replaceable beats clever and scalable.
- No success metric. Decide in advance what result means "go" and what means "change".
How long should an MVP take?
It depends on the product, but a focused MVP is typically 8–12 weeks. If your plan is much longer, the scope is probably bigger than a minimum.
Not sure which one you need?
Tell us where you are and we will say honestly which step makes sense, even if the answer is "not yet".
Want this applied to your business?
Growth Audit →