MVP vs Prototype vs Proof of Concept
Ordering the wrong one is the most expensive mistake in early product work. Each answers a different question — and only one of them is meant to have users.
What belongs in an MVP, and what to cut
Every feature you add to a first version costs three times: to build, to maintain for as long as the product lives, and in the delay before you learn whether anyone wanted the product at all. Most founders price only the first.
Cutting scope is therefore the highest-return activity available in an early build, and it is the one people resist hardest — because every feature on the list is there for a reason someone believes.
The test
For each feature, ask: if this were missing, would a real user still complete the thing they came to do?
If yes, it is not in version one. That is uncomfortably strict and it is the point. An MVP exists to answer one question — will people use this — and anything not required to answer that question is being paid for with the time you have before you find out.
| Feature | Can a user still finish without it? | Verdict |
|---|---|---|
| Sign up and sign in | No | Build it |
| The one core action | No | Build it — this is the product |
| Taking payment | Depends whether you are charging yet | Build if charging, cut if not |
| Password reset | No, they lock themselves out | Build it |
| Social login | Yes, email works | Cut |
| Admin dashboard | Yes, you can query the database | Cut, build a read-only view |
| Notification preferences | Yes | Cut, send the important ones |
| Onboarding tour | Yes | Cut, and watch where they get stuck |
The features almost everyone builds too early
- A settings page. Usually a collection of decisions nobody has asked for yet. Pick sensible defaults and wait for someone to complain.
- Roles and permissions beyond two. Owner and member covers most first versions. Elaborate permission models are expensive to build and much more expensive to change once data depends on them.
- A custom design system. You need the product to look credible, not to have a component library. That decision belongs to the version with users.
- Analytics dashboards for your customers. Almost always requested, almost never used in the first months. Ship the data export instead and see who asks for more.
- Multi-language support. A structural decision that doubles the surface area. Postpone until a market demands it.
- Your own authentication. There is no upside and a large downside. Use a provider.
What you cannot cut, even though it is invisible
There is a second list, and it is the one that gets cut by teams trying to move fast — which is how an MVP becomes something that has to be rebuilt within a year.
- Authentication that is actually secure. Sessions, password storage, rate limiting on login. The OWASP Top 10 is the reference; none of this is optional because the product is early.
- A sensible data model. The thing that is genuinely expensive to change later. Feature code is cheap to rewrite; a schema with production data in it is not.
- Deployment and monitoring. If you cannot deploy reliably and cannot tell when it is broken, you do not have a product in production — you have one on a server.
- Backups, tested. An untested backup is a belief. Restore one before launch, not after an incident.
- Somewhere errors go. You need to hear about failures from your tooling rather than from a customer.
These are the lines that get left out of cheap quotes, which is a large part of why the cheapest quote is rarely the cheapest build — see what an MVP costs.
Cutting is not the same as building it badly
There is a real difference between a small product built properly and a large product built carelessly, and "MVP" is often used to justify the second.
Cut features. Do not cut the quality of the features you keep. A first version with four things that work is a product; one with twelve things that half-work is a demo that will be rebuilt. MVP versus prototype versus proof of concept covers which of the three you are actually building — that decision changes what "good enough" means.
How to hold the line when it matters
The scope argument does not happen at the start, when everyone agrees to be disciplined. It happens in week two, when something looks easy and someone asks whether it could just be added.
- Write down the one question this version has to answer, and keep it visible.
- Keep a "not now" list rather than saying no. Features on a list stop being reargued.
- Agree who decides. Scope with two owners expands.
- Fix the date, flex the scope. If nothing may be cut, the date is decorative — how long an MVP takes covers why.
What we do
Scoping is the first thing that happens on an MVP build, and the most useful output is usually the list of things we talked you out of. We will tell you which features are in version two, and we would rather lose a project than build twelve half-features and call it a product.
Frequently asked questions
What features should an MVP include?
Only what a real user needs to complete the thing they came to do: sign up and sign in, password reset, the one core action the product exists for, and payment if you are charging. Test each feature by asking whether a user could still finish without it — if the answer is yes, it belongs in version two rather than version one.
What should I cut from my MVP?
Social login, a settings page, roles beyond owner and member, a custom design system, customer-facing analytics dashboards, multi-language support and an onboarding tour. A useful tie-breaker for anything else: could you do it manually for the first fifty users without them noticing? Onboarding, moderation and matching usually qualify, and doing it by hand teaches you what is worth automating.
What can't you cut from an MVP?
Secure authentication, a sensible data model, reliable deployment and monitoring, tested backups, and somewhere errors are reported. These are invisible to users and are the lines most often missing from a cheap quote. Feature code is cheap to rewrite later; a schema with production data in it and a security hole are not.
Does building a minimal MVP mean building it badly?
No, and conflating the two is how products get rebuilt within a year. Cut the number of features; do not cut the quality of the ones you keep. A first version with four things that genuinely work is a product. One with twelve things that half-work is a demo, and you will pay to build it again.
References
- OWASP Top Ten — OWASP
Keep reading
How long does an MVP take?
Three to six weeks for most first versions. The interesting question is not the estimate — it is which five things move it, because four of them are yours.
MVP Development Cost in 2026
Most MVP quotes are wrong for the same reason: they price a feature list instead of a decision. Here are the real ranges and what actually moves them.