The difference between an MVP and a prototype is one of those things that sounds simple but trips up a lot of founders. I've had dozens of conversations where someone says "I need an MVP" and what they actually need is a prototype. Or the reverse.
Getting this wrong costs time and money. So let me break it down based on 12+ years of building products for startups and enterprise companies.
The Simple Version
A prototype answers the question "does this idea make sense?"
An MVP answers the question "will people pay for this?"
That's the core difference. Everything else flows from there.
A prototype is a model. It looks like a product but it doesn't fully work. You can click through it, show it to people, get feedback. But nobody is signing up or entering their credit card.
An MVP is a real product. Stripped down, bare-bones, maybe ugly. But it works. Real users can sign up, use it, and ideally pay for it. You're collecting real data about real behaviour.
When to Build a Prototype
Build a prototype when you're still figuring out what to build.
I had a client come to me last year with a concept for a SaaS tool in the strata management space. They had a 12-page pitch deck with flowcharts and bullet points. Investors weren't biting. Nobody could picture what the product actually was.
We spent a week building a clickable prototype. It looked like a real app. You could click through the dashboard, see how notifications would work, preview the reporting flow. It wasn't functional. No database, no backend, no real data. Just screens connected together.
That prototype got them two investor meetings in the following month. Not because the product was built. Because people could finally see it.
Build a prototype when you need to:
- Show investors or stakeholders what you're planning
- Test whether the user experience makes sense before writing code
- Get feedback from potential users on the concept
- Align your team on what you're actually building
- Reduce the risk of building the wrong thing
A good prototype takes anywhere from a few days to two weeks. At FELTLAB, I've built prototypes in as little as three days when the scope is tight and the founder knows what they want.
When to Build an MVP
Build an MVP when you already know what to build and need to prove that people want it.
The difference is confidence. With a prototype, you're exploring. With an MVP, you're validating. You've done the thinking. You've talked to potential customers. You might have even shown them a prototype. Now you need the real thing.
An MVP has working functionality. Users can sign up, perform the core action, and get value from the product. It doesn't need every feature. It needs the one feature that solves the core problem.
I built a fan voting app recently. The MVP had one job. Let NRL fans vote 3-2-1 on best players after each match. No private groups, no historical stats, no social features. Just voting and a leaderboard. It launched with that and got 200+ signups before the season even started.
That's what an MVP should do. Answer one question with real data.
Build an MVP when you need to:
- Validate that people will actually use your product
- Start generating revenue, even small amounts
- Get traction metrics to show investors
- Learn what users actually do (not what they say they'll do)
- Build a feedback loop for your next iteration
The Key Differences Side by Side
Purpose. A prototype tests the concept. An MVP tests the market.
Functionality. A prototype is a simulation. An MVP is working software.
Users. A prototype is shown to stakeholders and testers. An MVP is used by real customers.
Data. A prototype gives you qualitative feedback ("this is confusing" or "I love this flow"). An MVP gives you quantitative data (signups, retention, conversion rates).
Timeline. A prototype takes days to a couple of weeks. An MVP takes two to six weeks depending on complexity.
Cost. A prototype runs $2,000 to $8,000 AUD. An MVP runs $10,000 to $50,000 AUD for most early-stage products. At FELTLAB, I run fixed-price sprints at $15,000 AUD that take a product from concept to shipped MVP in two to three weeks.
The Mistake Most Founders Make
The most common mistake I see is skipping the prototype and going straight to an MVP. That works sometimes. If you're a domain expert who deeply understands your users and the problem, you can skip ahead.
But most founders aren't in that position. They have a hypothesis. They think they know what users want. And they're eager to start building.
So they spend $30,000 and three months building an MVP. They launch it. Nobody uses it. Not because the code is bad. Because the product solved the wrong problem, or solved it in a way that didn't click with users.
A $5,000 prototype would have caught that in two weeks.
The second mistake is the opposite. Getting stuck in prototype mode forever. Running endless user tests, tweaking screens, doing one more round of feedback. At some point you need to ship real software and see what happens. Prototypes can only tell you so much. The real learning starts when people use a real product.
Which One Should You Build First?
Here's my framework. It's not complicated.
Start with a prototype if any of these are true:
- You haven't talked to at least 10 potential users
- You're not sure which feature is the "one thing" your product needs
- You're planning to raise funding and need something to show
- The concept is complex enough that people struggle to understand it from a pitch deck
Jump straight to an MVP if:
- You've already validated the concept through conversations, surveys, or a prototype
- You have a clear, narrow scope for version one
- You're bootstrapping and need revenue fast
- The product is simple enough that building it is faster than prototyping it
For some products, the line between prototype and MVP is blurry. A landing page with a signup form can be both. A no-code tool with limited functionality can be both. Don't get too precious about labels. Focus on what you're trying to learn.
The Fastest Path From Idea to Working Product
Whether you need a prototype or an MVP, the goal is the same. Get something in front of real people as fast as possible.
I've seen too many founders burn through six months and $100,000 building something nobody asked for. The smartest founders I work with spend a few thousand on a prototype, validate it, then invest in a focused MVP sprint.
At FELTLAB, I help founders in Australia go from idea to shipped product in two to three weeks. One person, full-stack, no hand-offs between designers and developers. Just fast, focused execution.
If you're trying to figure out whether you need a prototype or an MVP, book a free discovery call and I'll give you a straight answer in 30 minutes.
FAQ
Can a prototype become an MVP?
Sometimes, but usually not directly. A prototype is built to look right, not to work right. The code (if there is any) is usually throwaway. It's better to treat the prototype as a blueprint and build the MVP fresh with proper architecture. That said, if you built a high-fidelity prototype in a framework like Next.js, some of the frontend work can carry over.
How much does a prototype cost compared to an MVP?
A clickable prototype typically costs $2,000 to $8,000 AUD. An MVP ranges from $10,000 to $50,000+ depending on complexity. The prototype is cheaper because you're building screens, not systems. No database, no authentication, no payment processing. Just enough to show the idea.
Do investors prefer to see a prototype or an MVP?
It depends on the stage. Pre-seed investors are usually happy with a strong prototype and evidence of customer discovery. Seed investors want to see an MVP with some traction. If you have 200 signups and a working product, that tells a stronger story than 50 slides ever will.
Should I build a prototype if I'm not raising funding?
Yes, if you're uncertain about the product direction. A prototype is cheap insurance. It forces you to make design decisions early and test them before you've written thousands of lines of code. Even if you're bootstrapping and plan to build everything yourself, spending a few days on a prototype will save you weeks of rework later.