MVP vs Prototype: What You Actually Need to Build First

In 2007, Nick Swinmurn walked into shoe stores, photographed their inventory, and listed the photos on a basic website. When someone ordered, he ran back to the store, bought the shoes at retail, and shipped them at a loss.

No warehouse. No inventory system. No custom logistics software.

That was the Zappos MVP. And it answered the only question that mattered: would people actually buy shoes online without trying them on first?

Compare that to a team I advised last year. They spent eight months building a "prototype" of their marketplace app. Custom backend. Native mobile apps. Real-time messaging. Payment integration.

Eight months later, they launched to crickets. Nobody used it. They had built the wrong thing for the wrong market.

Here is the confusion: they thought they were building an MVP. They were actually building a fully-featured product. And they did it before validating that anyone wanted it.

The MVP vs prototype distinction is not semantic. It determines whether you waste eight months or eight days learning what you need to know.

What Is a Prototype?

A prototype is a representation of your product that tests specific assumptions without being functional for real use.

The key word is representation. A prototype looks like your product, or demonstrates how it might work, but it is not the product itself.

Prototypes answer questions like:

• Can we build this technically?
• Do users understand the interface?
• Does this interaction pattern make sense?
• Will our core mechanism actually work?

Prototypes are disposable by design. You build them to learn, then throw them away. The prototype itself has no value. The learning has all the value.

Types of Prototypes

Paper prototypes: Sketched screens on paper. You can test user flows by having someone "click" through paper mockups while you swap screens manually. Sounds ridiculous. Works incredibly well for testing whether users understand navigation.

Figma/design mockups: Higher fidelity visuals that show what the product would look like. Users can click through static screens. Tests visual design, information hierarchy, and basic flows without writing code.

Wizard of Oz prototypes: The interface looks real, but there is a human behind the curtain doing the work. The user thinks they are interacting with software; they are actually interacting with you pretending to be software. This tests whether the value proposition works before you automate it.

Technical spike: Quick, throwaway code that tests whether something is technically feasible. Can we integrate with this API? Will this algorithm work on real data? The code gets deleted after the question is answered.

Clickable prototype: An interactive mockup that simulates the app experience. Tools like Figma, InVision, or Framer let you create something that feels like an app but has no real backend.

When to Build a Prototype

Prototypes shine when you face high uncertainty in specific areas:

Technical risk: You are building something that has never been built. Or you are using unfamiliar technology. A technical spike proves feasibility before you commit.

Novel interaction patterns: Your product requires users to behave in new ways. A clickable prototype tests whether people can figure out your interface without instruction.

Complex systems: The product involves many moving parts that need to work together. Prototyping the integration points prevents discovering they do not fit after months of work.

Expensive mistakes: Building the wrong thing would cost significant time or money. A paper prototype costs an hour. An eight-month build costs a year of your life.

Unproven user behavior: You are betting that users will do something they have never done before. A Wizard of Oz prototype tests whether they actually behave that way.

Prototype Examples That Worked

Palm Pilot origin: Jeff Hawkins, before building the first Palm Pilot, carried a block of wood in his pocket for weeks. When he wanted to check his calendar, he pulled out the wood block and pretended to tap on it. This "prototype" helped him understand how people would actually use a handheld computer. The form factor and interaction patterns came from weeks of pretending.

Airbnb's concierge MVP: Before building their platform, the Airbnb founders personally photographed apartments and created listings for hosts. They were the prototype of the system they would later automate. This taught them what hosts needed before they built the tools.

IBM's speech recognition study: In a famous 1984 experiment, IBM wanted to test whether people would use speech-to-text. Instead of building the technology (which barely existed), they had test subjects speak into a microphone while a hidden typist transcribed in real-time. Users thought they were testing speech recognition. IBM learned that the concept worked before investing in the technology.

What Is an MVP?

A Minimum Viable Product is a real product with the minimum features needed to deliver value to real customers and learn from their usage.

The key words are real product and real customers. An MVP is not a prototype. It is not a mockup. It is something people can actually use to solve their problem.

MVPs answer questions like:

• Will people pay for this?
• Which features actually matter?
• How do people use this in the wild?
• Can we acquire customers at reasonable cost?

Unlike prototypes, MVPs are not disposable. They are the foundation you will build on. Every MVP should be designed to evolve into your full product.

What Makes an MVP "Viable"

An MVP must be viable. It must actually work for real users.

This is where founders go wrong. They either build too little (not viable) or too much (not minimum).

Too little: A landing page that describes your product but does not deliver it. This might help gauge interest, but it is not an MVP. You have not proven that people will use the product, only that they are curious about the concept.

Too much: A fully-featured product that tries to serve every use case. This is not minimum. You have wasted months building features you do not know anyone wants.

Just right: A product with just enough functionality that early adopters can get real value from it. It might be ugly. It might be manual behind the scenes. But it works.

MVP Examples That Launched Billion-Dollar Companies

Dropbox (2007): Drew Houston could not get investors excited about "file syncing." So he made a 3-minute video demonstrating how Dropbox would work. Not a functional product. Just a screencast showing the concept.

He posted it to Hacker News. The waitlist went from 5,000 to 75,000 overnight.

Wait, you might say, a video is not an MVP, it is a prototype. True. But what came next was the MVP: a clunky, Windows-only file sync tool that barely worked but delivered real value to real users. The video validated demand. The MVP validated the product.

Buffer (2010): Joel Gascoigne validated Buffer with a two-page website. Page one explained the concept: schedule your tweets. Page two showed pricing plans. When you clicked a plan, you saw: "We are not quite ready yet. Leave your email."

That landing page was not the MVP. The MVP came weeks later: a bare-bones tool that actually scheduled tweets. Minimal interface. No analytics. No team features. Just the core function.

Zappos (1999): Nick Swinmurn did not build a warehouse, inventory system, or logistics operation. He took photos of shoes at local stores and listed them online. When someone ordered, he bought the shoes at retail and shipped them himself.

Terrible unit economics. But it proved the only thing that mattered: people would buy shoes online. The MVP was a manual operation that looked like an e-commerce site.

Groupon (2008): The first Groupon was a WordPress blog. Andrew Mason manually emailed PDF coupons to customers. There was no sophisticated deal platform. Just a guy sending PDFs.

It worked. The manual process proved the concept before they built the technology.

The Critical Difference: Learning Goals

Prototypes and MVPs both exist to learn. But they answer different questions.

Prototype Questions	MVP Questions
Can we build this?	Will people use this?
Does the interface make sense?	Will people pay for this?
Is this technically feasible?	What features matter most?
Do users understand the concept?	Can we acquire customers affordably?
Will this mechanism work?	Will users come back?

A prototype tests your solution. An MVP tests your business.

This distinction matters because it determines what you should build and in what order.

Decision Framework: Which to Build First

Use this framework to decide whether you need a prototype, an MVP, or something else.

Start with a Prototype When:

1. Technical feasibility is uncertain

If you are not sure whether your solution can be built, a prototype answers that before you invest in an MVP.

Example: You want to build an AI that analyzes legal contracts. Can modern LLMs actually do this reliably? A technical spike answers the question in days.

2. The interaction is novel

If your product requires users to do something they have never done before, a prototype tests whether they can figure it out.

Example: You are building a gesture-based interface for elderly users. A paper prototype reveals usability issues before you write code.

3. The cost of failure is high

If getting it wrong means months of wasted work, prototype first.

Example: You are building enterprise software that integrates with complex systems. A technical spike tests the integration before you commit.

4. You have not validated the problem

If you are not sure the problem exists or is painful enough, you need customer interviews before either a prototype or MVP.

Do not skip this step. Many founders jump to building before validating that anyone cares about the problem they are solving.

Skip Straight to MVP When:

1. The problem is validated

You have talked to potential customers. You have evidence that this problem is real, painful, and worth paying to solve.

2. The solution is straightforward

There is no technical risk. You know how to build it. You just need to build the minimum version.

3. Speed matters more than perfection

First-mover advantage exists in your market. Or you are testing multiple ideas and need to fail fast.

4. Manual processes can substitute for technology

Like Zappos buying shoes at retail, you can deliver value through human effort before automating.

The Hybrid Approach

Often, you need both, in sequence:

1. Validate the problem (customer interviews, not building anything)
2. Prototype the risky parts (if there is technical uncertainty or novel UX)
3. Build the MVP (minimum functional product for real users)
4. Iterate based on usage (expand features based on evidence)

The mistake is combining steps or skipping them entirely.

Common Mistakes and How to Avoid Them

Mistake 1: Building a "Prototype" That Is Really a Product

Symptoms: Your prototype took months. It has a backend. It could be launched.

This is not a prototype. Prototypes are meant to be thrown away. If you are emotionally attached to your "prototype," you built too much.

Fix: Set a time limit. Paper prototypes: 1 hour. Clickable prototypes: 1 week. Technical spikes: 3 days. If you exceed these, you are overbuilding.

Mistake 2: Calling Your MVP Done Before It Is Viable

Symptoms: You have a landing page and an email list. You call this your MVP.

A landing page tests interest, not viability. An MVP must deliver real value. If users cannot use your product to solve their problem, it is not viable.

Fix: Ask yourself, can a user complete the core task and get real value today? If not, you do not have an MVP yet.

Mistake 3: Building Too Much in Your MVP

Symptoms: Your MVP has user accounts, admin dashboards, analytics, multiple user roles, and a mobile app.

This is not minimum. You are building features you do not know anyone wants.

Fix: List every feature in your MVP. For each, ask: can we learn what we need without this? Cut ruthlessly. Launch with half the features you think you need.

Mistake 4: Skipping Problem Validation Entirely

Symptoms: You went straight to building because the problem seemed obvious.

The problem was obvious to you. That does not mean it is painful enough for others to pay to solve.

Fix: Before any building, talk to 20 potential customers. Ask about their problems without pitching your solution. If you cannot find 20 people who independently describe your problem, stop and reconsider.

Mistake 5: Treating the Prototype as the Product

Symptoms: Your prototype "worked" so you launched it to customers.

Prototypes are research tools. They are not built to scale, handle edge cases, or survive real usage.

Fix: Accept that the prototype taught you something. Now build the real thing using those learnings. The prototype code should be deleted, not deployed.

The Validation Sequence

Here is the complete sequence for taking an idea from concept to product:

Step 1: Problem Validation (No building)

• Talk to 20+ potential customers
• Validate that the problem exists and is painful
• Confirm willingness to pay for a solution
• Time: 1-2 weeks

Step 2: Solution Exploration (Lightweight prototypes)

• Sketch possible solutions
• Create paper or Figma prototypes
• Test with users for understanding
• Time: 1-2 weeks

Step 3: Feasibility Testing (If needed)

• Technical spikes for risky components
• Wizard of Oz tests for novel behaviors
• Time: Days to 1 week

Step 4: MVP Build

• Minimum features for real value
• Manual processes where possible
• Focus on learning, not perfection
• Time: 4-8 weeks

Step 5: Launch and Learn

• Get the MVP in real users' hands
• Measure what matters (usage, retention, willingness to pay)
• Iterate based on evidence

Most failed startups skip steps 1-3 and spend 6+ months on step 4.

What This Means for Your Startup

If you are early in your journey:

1. Do not build anything yet. Talk to customers first. Validate the problem before the solution.

2. Prototype the risky parts. If there is technical or UX uncertainty, spend days (not months) testing those assumptions.

3. Build the smallest MVP possible. Smaller than you think. Remember, Dropbox's MVP was a video. Buffer's was a landing page with fake pricing. Zappos was a guy buying shoes at retail.

4. Launch before you are ready. If you are not embarrassed by your MVP, you waited too long.

5. Let usage guide features. Build what users need, not what you think they need.

The difference between successful founders and failed ones is not the quality of their ideas. It is the speed at which they learn which ideas are worth pursuing.

Prototypes and MVPs are learning tools. Use them correctly, and you compress months of uncertainty into weeks of evidence.

Accelerate Your Validation

Before building anything, you need evidence that your idea is worth pursuing. Market size. Competitor analysis. Customer segments. Regulatory considerations.

Bedrock Reports compresses weeks of market research into minutes. Get investor-grade validation data with cited sources, no hallucinations.

Use it to answer the questions that come before the prototype vs MVP decision: Is this problem real? Is the market big enough? What do competitors do well and poorly? Why now?

Then build the right thing first.

Keep Reading

• How to Validate a Business Idea - The complete validation playbook before you build anything
• The Startup Validation Checklist - 15 questions to assess any idea before building
• Why ChatGPT Cannot Validate Your Startup Idea - The dangers of AI-generated market research without citations
• Founder-Market Fit Guide - Why who you are matters as much as what you build

---

Ready to validate before you build? Run a Bedrock Reports validation and get evidence-backed market intelligence in minutes, not weeks.