What is the difference between an MVP and a prototype?

A prototype is a testable mock-up of a product or feature — often not functional — used to validate design decisions and user interactions before investing in development. An MVP (Minimum Viable Product) is a functional, shippable product that delivers real value to real users and is used to validate business assumptions like willingness to pay and retention. Prototypes test 'Does this design work?' MVPs test 'Does this business work?'

Should you build a prototype before an MVP?

Usually yes. Prototyping before building an MVP reduces the risk of building the wrong thing. Use a prototype (clickable mockup, Figma demo, paper prototype) to test the user experience with 5-10 target users. Incorporate their feedback, then build the MVP with the validated design. Skipping prototyping typically leads to MVPs that work technically but fail at the UX layer — costing more to fix after the fact.

What makes a good MVP?

A good MVP solves one specific, painful problem for a clearly defined customer segment better than the available alternatives. It is functional — users can actually use it to accomplish a real task. It includes enough features to validate your core business hypothesis. It excludes every feature that isn't essential to that validation. Dropbox's MVP was a demo video. Airbnb's MVP was a website with three listings in San Francisco. Neither had everything; both had enough to validate the core value proposition.

How do you know when to build an MVP vs a prototype?

Build a prototype when you need to test design decisions, user flows, or interaction patterns before committing to development. Build an MVP when you need to validate whether real users will use and pay for your product in the real world. If the biggest uncertainty is 'Will users understand how this works?', build a prototype. If the biggest uncertainty is 'Will anyone actually pay for this?', build an MVP.

Can an MVP be a no-code tool or landing page?

Yes. The MVP's purpose is to validate assumptions with minimal investment, not to demonstrate technical capability. A landing page with a waitlist validates demand. A Typeform-powered service validates willingness to pay. A no-code tool built in Webflow or Glide validates the core workflow. The right MVP format depends on your primary hypothesis: what is the most important assumption you need to validate before investing in a full build?

MVP vs Prototype: What's the Difference? (With Real Examples)

Quick Answer

A prototype tests design and usability — it’s a mock-up that helps you validate whether users understand your product before you build it. An MVP tests business viability — it’s a real, functional product used by real customers to validate whether people will use and pay for your solution. Build prototypes to answer “Does this design work?” Build MVPs to answer “Does this business work?”

What Is a Prototype?

A prototype is a simulation of a product or feature, built to test assumptions about design, usability, and user experience before investing in full development.

Key characteristics:

Not necessarily functional
Often disposable (built to learn, then discarded)
Used with a small test group (5-10 users)
Fast to build (hours to days)
Tests design questions, not business questions

Types of prototypes:

Type	Description	Best for
Paper prototype	Sketched screens, user moves through them	Early concept testing
Clickable mockup	Figma/InVision/Framer with tappable hotspots	Interaction design validation
Wizard of Oz	Humans power the “automation” behind the scenes	AI/automation concepts
Concierge prototype	Deliver the service manually before automating	Service workflows
Video prototype	Demo video of how the product would work	Demand validation (Dropbox approach)

What prototypes test:

Can users navigate the flow without instructions?
Do users understand what each screen is for?
Are the labels, buttons, and CTAs clear?
Does the UX match how users already think about the problem?

What Is an MVP?

A Minimum Viable Product is the simplest version of a product that delivers real value to real users and can be used to test your core business hypothesis.

Key characteristics:

Functional — users can accomplish real tasks
Shipped to real users in the real world
Used to validate business assumptions (demand, retention, willingness to pay)
Tests the riskiest business question with the least investment
Expected to evolve based on user feedback

What MVPs test:

Will users actually use this?
Will they pay for it?
Will they come back?
Does our core value proposition resonate?

MVP vs Prototype: Comparison Table

Dimension	Prototype	MVP
Purpose	Test design and usability	Test business viability
Functional?	Usually not	Yes
Built for	5-10 test users	Real users in the real world
Validates	UX, flows, design decisions	Demand, retention, willingness to pay
Build time	Hours to days	Weeks to months
Cost	Very low	Low to medium
Discarded after?	Usually yes	Usually no — iterate on it
Shipped publicly?	No	Yes
Success metric	Task completion, confusion points	Retention, activation, revenue

Real Examples

Prototypes

Dropbox: Before building anything, Drew Houston recorded a 3-minute video showing how Dropbox would work. The video drove 70,000 waitlist signups overnight. This was a prototype (a video simulation of the product) that validated demand before writing a line of code.

Figma: The founding team built clickable Figma mockups of Figma’s own interface to test whether designers understood the collaborative editing concept. The meta-prototype validated the UX before building the real-time sync infrastructure.

MVPs

Airbnb: The founders rented out their own apartment with air mattresses to three strangers attending a conference in San Francisco. The “product” was a website with three listings. This functional MVP validated that strangers would pay to stay in someone’s home.

Zappos: Nick Swinmurn went to local shoe stores, photographed shoes, listed them on a website, and manually fulfilled orders. No inventory, no warehouse. The functional MVP validated that people would buy shoes online — before building any e-commerce infrastructure.

The Build Order: Prototype → MVP → Product

Most successful products follow this sequence:

Step 1: Paper/concept prototype Sketch the core flow. Walk 3-5 target users through it. Identify confusion before touching Figma.

Step 2: Clickable prototype Build in Figma or Framer. Run 5-10 usability tests. Iterate until users can navigate it without help.

Step 3: MVP Build only the features that survived the prototype stage. Ship to 10-100 real users. Measure: Do they activate? Do they return? Would they pay?

Step 4: Product iteration Based on MVP learnings, build the next version. Now you’re building with real user data, not assumptions.

When to Skip Directly to MVP

Sometimes prototyping isn’t necessary:

You’ve already done extensive research in this domain
The core interaction is simple and well-understood
You’re iterating on an existing product, not starting from scratch
Speed to market is more valuable than the risk reduction from prototyping

The question is: what’s your biggest risk? If it’s “Will users understand this?” — prototype first. If it’s “Will anyone actually pay?” — skip straight to MVP.

Common Mistakes

❌ Treating an MVP like a prototype Building an MVP that’s not functional, then showing it to 5 users as a “test.” This generates design feedback, not business validation.

✅ Instead: If it’s not functional and users can’t use it in the real world, it’s a prototype. Call it that, test accordingly.

❌ Over-engineering the MVP Adding features “just in case” that aren’t essential to validating the core hypothesis. This delays learning and wastes resources.

✅ Instead: For every feature you’re considering including, ask: “What assumption does this validate?” If it doesn’t validate your riskiest assumption, cut it.

❌ Calling a full product an MVP Many teams call their product an MVP to justify shipping something unpolished. An MVP isn’t a product with bugs — it’s a deliberately minimal product designed to test one thing.

✅ Instead: Define your core hypothesis before building. Build only what’s needed to test it. Everything else is scope creep.