MVP vs prototype vs proof of concept: which do you build first?
By Sarmed, co-founder of Impleko
The short answer: A proof of concept (POC) tests whether something can be built. A prototype shows what the product will look like and how people will move through it, usually without working code behind it. An MVP, or minimum viable product, is the first working version real users can sign up for, built to test whether people want it and will pay. Most products go in that order: proof of concept, prototype, MVP. Many skip the proof of concept when the technology is already proven.
POC vs prototype vs MVP at a glance
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Can this be built? | Will people understand and like it? | Will people use it and pay for it? |
| Who sees it | Your team, maybe investors | Your team, test users, investors | Real customers |
| Working code | Some, just for the risky part | Usually none; clickable screens | Yes, production code |
| Typical time | Days to a few weeks | Days | Weeks |
| What you get | A yes or no on feasibility | Feedback on design and flow | Usage data, feedback and first revenue |
| What comes next | A prototype | An MVP | Version two, built on what users do |
What is a proof of concept?
A proof of concept is a small technical test that answers one question: can this be done? It's built only around the riskiest part of the idea, such as whether an AI model can read a certain kind of document accurately, or whether two systems can share data in real time. A POC isn't meant for users and is usually thrown away. You need one only when the technology is genuinely uncertain; for a booking app or a client portal, you can skip it.
What is a prototype?
A prototype is a model of the product that shows the main screens and how people move between them. Most prototypes are clickable designs with no working back end: you can tap through sign-up, the main feature and checkout, but no real data is saved. Prototypes are fast to make and cheap to change, which makes them the best way to test the design with users and to show investors what you're building before you pay for a full build.
What is an MVP?
An MVP, or minimum viable product, is the smallest version of a product that real users can sign up for and use, built to prove the idea works in the real world. The term was coined by Frank Robinson in 2001 and made popular by Eric Ries in "The Lean Startup" in 2011. An MVP has real code, real accounts and usually real payments, but only the features needed to test the main idea. Everything else waits until users show you what they need.
The word "minimum" is often misread. An MVP should be small, not broken: the core feature has to work well, or users leave before you learn anything.
Do you need all three?
Usually not. Here's how to decide:
- Skip the proof of concept if the technology is already proven, which is true for most web apps, portals, marketplaces and SaaS products.
- Always make a prototype. It costs days, not weeks, and catches design problems when they're cheap to fix.
- Build the MVP once the prototype has been tested with a few real users or investors.
The most common mistake is skipping the prototype and going straight to the build, then rebuilding screens after the first users get confused.
Common MVP mistakes
- Too many features. If the MVP takes months, it isn't minimum. Cut to the one problem and one type of user.
- No way to measure. Add enough tracking to see who signs up, what they use and where they drop off.
- Throwaway code. An MVP should be production code you can build on, not a demo you have to rewrite.
- No payment test. If you plan to charge, charge in the MVP. Sign-ups alone don't prove people will pay.
- Code you don't own. Make sure the code lives in your own GitHub from the first commit.
Which should you build first?
Build a proof of concept first if: the core of your idea depends on technology that may not work, such as a new AI feature on unusual data.
Build a prototype first if: you need to test the design, raise money, or explain the product to your team before you commit to a build.
Build the MVP if: the design has been tested and you're ready to put the product in front of paying users.
How Impleko builds them
We start every product with a scoping call and a fixed quote, show a clickable prototype in 1 day, then build the MVP in weeks on Next.js, React, Node.js, TypeScript, Supabase and Stripe. Our QA team tests every release, and the code lives in your GitHub from the first commit. When an idea depends on an untested AI feature, we test that part first. See MVP and SaaS development.
Questions about MVPs, prototypes and proofs of concept
What's the difference between an MVP and a prototype?
A prototype is a model of the product, usually clickable screens without working code, used to test the design. An MVP is a working product real users can sign up for and use, built to test whether they want it and will pay.
What's the difference between an MVP and a proof of concept?
A proof of concept tests whether the technology can work and is usually only seen by your team. An MVP is a working product for real customers, built to test whether there's demand.
How long does it take to build an MVP?
Most MVPs take weeks, not months, when the scope is limited to the smallest version worth launching. Impleko delivers a clickable prototype in 1 day and a working MVP in weeks, with the date in the quote.
Can a prototype become the MVP?
The design can, but the prototype itself usually can't, because most prototypes have no working code behind the screens. The MVP is built in production code using the tested design.
Do investors want a prototype or an MVP?
It depends on the stage. A prototype is often enough to explain the idea early on. An MVP with real users and usage data is much stronger evidence that people want the product.
Who coined the term MVP?
The term minimum viable product was coined by Frank Robinson in 2001 and made popular by Eric Ries in his 2011 book "The Lean Startup".