What is the difference between a minimum viable product and a prototype?
A prototype is a low-cost, clickable model built with simple tools to help founders clarify their product vision. A minimum viable product (MVP) is a functional, bare-bones release designed to test whether real customers will pay for a solution to a painful problem.
TL;DR:
A prototype is a cheap, simple-tool phase used when the unknown is "what are we even building?" It forces founder clarity before committing a team.
A functional MVP is the narrowest real solution that fixes a painful customer problem. It is used when the unknown is "will a real customer get value and pay for this?"
Choosing between an MVP vs prototype is a learning-mode decision, not a build-scope decision.
The real startup prototype difference is not polish or size, but which risk the artifact tests.
The Rebuild Mistake
A founder has no traction. The product feels wrong. Rebuilding the interface seems like the obvious next step.
Instead, they should test if anyone wants the outcome badly enough to pay for it.
Consider an AI-personalized workout app. The founder had zero traction. Rather than rewriting the codebase, they ran a 14-day concierge pilot. They sold the concept to 15 real buyers, but the "AI personalization" was just a human sending WhatsApp messages.
They tested demand manually. Only when 40% of those testers wanted to buy the £60 subscription did the team write the automation code. The core question was not how much to build, but what they needed to learn.
Learning Mode, Not Build Scope
Founders often treat prototypes and MVPs as the same thing, just different sizes of build scope. This is a mistake. The choice between a prototype and a minimum viable product is about choosing the right learning mode.
When to Prototype
Prototyping with simple tools is useful because it forces you to clarify what the product should be. A prototype answers: "What are we actually building?"
Use a prototype when your team needs to align on vision. It is the cheapest way to explore an idea without committing engineering resources.
But a prototype cannot measure willingness to pay. When you show a user a clickable design and ask "what do you think?", you collect polite lies instead of real validation.
When to Build a Functional MVP
A functional MVP answers: "Will anyone get enough value to care?"
You build an MVP to validate painful demand and real willingness to pay. It must be the smallest real experience that validates customer value, similar to the original Lean Startup methodology. For a closer look at this baseline, read our guide on what is an MVP.
The AI Vibe-Coding Trap
Because AI makes building cheap, founders sometimes skip the prototype phase and just ship an MVP.
They add light and dark themes. They build scalable onboarding flows. They build "big SaaS" polish. The result is vibe-coding: using AI to build what people do not need, simply because it is fast.
Building faster does not make weak evidence stronger. As noted in The Mom Test, the goal is to start the learning process. An MVP must fix the most painful problem for the user. Do not distract yourself with cheap features. Keep your MVP narrowly focused.
Practical Framework: Prototype vs. Functional MVP
Choosing the right fidelity level prevents wasted engineering time while securing accurate market feedback.
Clickable Prototype
Primary Unknown: What are we building?
Cost / effort: Low (design tools)
Validation Fidelity: Low (opinions, clicks)
Best For: Internal clarity, testing workflow fit, finding objections.
What to Measure: Confusion, objections, workflow fit.
Weak Signal: "I like it"
Strong Signal: Detailed workflow corrections
Functional MVP (or Concierge)
Primary Unknown: Will they pay for this value?
Cost / effort: Medium to High (coding or manual labor)
Validation Fidelity: High (usage, payment intent)
Best For: Testing real usage, proving demand, securing alpha customers.
What to Measure: Activation, repeated use, manual onboarding notes, payment intent.
Weak Signal: Clicks on a landing page (weak demand signal)
Strong Signal: Repeated use, entering credit card details
If you need automation proof, consider a concierge MVP first. Deliver the value manually, just like the WhatsApp workout app. You can automate later.
Moving Forward With Alpha Customers
Once you decide to build a functional MVP, your goal is to find your first users.
Do not try to build a scalable acquisition process yet. Find your first alpha customers manually. Go where they are. Invite them. Onboard them yourself. See if they get actual value out of the product. If you need a step-by-step approach for this phase, read how to build a minimum viable product in B2B.
If you want extreme proof of demand, some teams use fake-door testing. They charge a customer's card for a product that does not exist yet. Then, they immediately refund the charge, cite capacity limits, and put the user on a waitlist. This proves real intent with real money, aligning with the idea of a minimum feature set that sells. However, this approach carries trust and compliance risks, so use it carefully.
FAQ
What is the difference between a prototype and an MVP?
A prototype is a low-cost model built to clarify your product vision before writing code. An MVP is a functional release built to test if real customers will pay for your solution.
If AI makes building cheap, should we skip prototypes and just ship an MVP?
No. Cheap building makes it easier to build things people do not need. Use a prototype to clarify what you are building before you commit. Use a functional MVP when you need to know if a real customer will pay for a solved problem.
Does an MVP need scalable onboarding?
No. Early on, manual onboarding is better. It gives you a deep understanding of your customer's context and workflow. That knowledge makes your product hard to copy.
Can a manual service count as an MVP?
Yes. A concierge MVP validates the core value even if a human does the work behind the scenes. If the customer experiences the promised value, it is a valid MVP.
