MVP vs Prototype vs POC: Which Should You Build First?

Founders use these three words as if they meant the same thing, and plenty of agencies do too. They don't. A proof of concept, a prototype and an MVP each answer a different question and take a different amount of time. Pick the wrong one and you can spend three months answering a question nobody was asking.

This guide is for founders and product owners deciding where their first money goes. We build MVPs and SaaS products at Arrowbin, and the first thing we ask about any new idea is which assumption would kill it if it turned out to be wrong. That question decides which of the three you need.

What's the difference between a POC, a prototype and an MVP?

A proof of concept (POC) tests whether something can be built. A prototype tests whether people understand it and can use it. A minimum viable product (MVP) tests whether people will use it for real and pay for it.

The quickest way to keep them apart is to ask who sees each one. Only your team sees a POC. A handful of test users see a prototype, and they know it's a test. Real customers use an MVP, and they don't care that it's version one.

• Purpose

  Proof of concept (POC)

  Check that one risky technical piece works

  Prototype

  Show how it will look and flow, and watch people use it

  MVP

  Put a working first version in real customers' hands

• Question it answers

  Proof of concept (POC)

  Can we build it?

  Prototype

  Will people understand it and want to use it?

  MVP

  Will people use it for real, come back and pay?

• Who it's for

  Proof of concept (POC)

  Your own team, or an investor's technical reviewer

  Prototype

  Five or so test users, plus stakeholders and investors

  MVP

  Real customers in your target market

• Fidelity

  Proof of concept (POC)

  Rough code with no real interface

  Prototype

  Sketches to clickable mockups, with nothing working behind them

  MVP

  Production code for one core workflow, with real accounts, data and payments

• Typical time

  Proof of concept (POC)

  Days to a few weeks, sized to one question (our view)

  Prototype

  Days to 2 weeks (Arrowbin estimate)

  MVP

  6–14 weeks; complex SaaS 14–20 (Arrowbin estimate)

• Typical cost

  Proof of concept (POC)

  Engineer time for the length of the test; we don't publish a range

  Prototype

  Design time plus a few test sessions; we don't publish a separate range

  MVP

  $5,000–$30,000 lean, $40,000–$120,000 polished (Arrowbin estimate)

• What you can learn

  Proof of concept (POC)

  Whether the hard part works, and what it costs to run

  Prototype

  Where people get stuck, what they expect to see, which flow to build

  MVP

  Whether people sign up and return, whether they pay, and what they ask for next

• What it can't tell you

  Proof of concept (POC)

  Whether anyone wants the product

  Prototype

  Whether people will pay, or whether the product can be built

  MVP

  Whether it will scale, or what the full product should become

• What happens to it afterwards

  Proof of concept (POC)

  Usually thrown away; the findings are kept

  Prototype

  Becomes the design reference for the build

  MVP

  Becomes version one, and you keep building on it

• Next step

  Proof of concept (POC)

  A prototype or an MVP, or stop if it failed

  Prototype

  An MVP, or another round of design and testing

  MVP

  Iterate on what users do, or change direction

Most comparisons of the three leave out two of those rows, and they're the most useful ones. 'What it can't tell you' stops you reading too much into a good result. 'What happens to it afterwards' stops POC code from quietly becoming your product.

(opens the full-size chart in a new tab)

What is a proof of concept, and when do you need one?

A proof of concept is a small, usually throwaway piece of work that checks whether one risky technical part of your idea works. You need one when there's a real chance the hard part can't be done, or can't be done at a price that makes sense.

The term comes from engineering. NASA's technology readiness levels put the proof-of-concept model at level 3 of 9, well before anything the scale calls a prototype. Software uses it the same way: prove the core mechanism on its own, with no interface and no users.

Say you want a tool that reads supplier invoices and fills in your accounting system. The risky part isn't the dashboard. It's whether extraction is accurate enough on your suppliers' real PDFs. A POC runs a couple of hundred of those files through the extraction step and counts how many come out right. That's the whole job. Other good POC candidates:

• An AI feature where accuracy or the cost per request could break the business case.
• An integration with an API that's badly documented, heavily rate-limited or only partly public.
• A hard performance target, such as matching thousands of records in under a second.
• A device or sensor the software has to talk to.

Write the pass mark before you start. 'At least 95% of invoices extracted correctly, at a cost per invoice we can live with' is a POC. 'Let's see if it works' is a hobby.

A passing POC tells you it can be built. It says nothing about whether anyone wants it. Gartner predicted in 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. The reasons it gave were poor data quality, weak risk controls, rising costs and unclear business value. Only some of those are about whether the technology worked.

Most web and SaaS products don't need a POC at all. Accounts, dashboards, payments and email are solved problems. If your idea is a better workflow built from standard parts, your risk is demand or usability, and a POC would spend weeks proving that Postgres works.

What is a prototype, and what can it tell you?

A prototype is a model of the product that people can look at or click through, built to test whether they understand it and can use it. It usually has nothing real behind the screens: no database, no payment logic.

Nielsen Norman Group describes a prototype as a hypothesis, a candidate design you test by watching people use it. Fidelity runs from paper sketches, where a person plays 'the computer', to clickable mockups that often look like live software to the people testing them. Low fidelity is quicker to change in the middle of a test. High fidelity lets you test whole workflows.

It doesn't take long. GV's design sprint builds its prototype in a single day, on the reasoning that 'a realistic façade is all you need to test with customers'. Our own figure for a clickable prototype is days to 2 weeks.

It doesn't take many people either. Jakob Nielsen's five-user rule says the first five test users uncover about 85% of the usability problems, and that three rounds of five, with fixes in between, beat one round of fifteen. His model assumes your users are fairly alike. If you sell to two very different groups, test each group.

(opens the full-size chart in a new tab)

What a prototype can't tell you is whether anyone will pay. People are polite in test sessions. They'll say they love it, and some will mean it, but clicking through a mockup costs them nothing. You only learn about money when you ask for it.

One warning about the word itself. In engineering, a prototype is often a working model, and NASA's scale only reaches 'a fully functional prototype' at level 6. In software design it usually means a clickable mockup. If a vendor quotes for a prototype, ask which kind they mean before you compare prices.

Prototyping is design work, and it's where our UI/UX design and prototyping work starts. It's also the cheapest place to change your mind. The NN/g article puts it plainly: 'Ripping up code is very expensive.'

What is an MVP, and why isn't it just a smaller product?

An MVP is the first version of your product that real customers can use for real. It's built around one core workflow so you can learn whether people adopt it and pay. It's working software, and a demo doesn't count.

Eric Ries, who popularized the term, defined it in 2009 as the version of a new product that lets a team 'collect the maximum amount of validated learning about customers with the least effort'. In the same post he wrote: 'MVP, despite the name, is not about creating minimal products.' The goal is learning. Small is how you get there quickly.

That's why an MVP needs the dull parts a prototype skips. Sign-up has to work, data has to persist, payments have to go through, and someone has to see the errors. Without those you aren't learning how customers behave. You're watching them hit bugs.

Demand is the risk that sinks a lot of products. In CB Insights' analysis of why startups fail (March 2026), poor product-market fit came up in 43% of the VC-backed shutdowns where a cause could be identified. Running out of money topped the list at 70%, but the report calls that 'almost always the final cause of death, not the root problem'. An MVP exists to find out about demand before the money runs out.

By our estimates most MVPs take 6 to 14 weeks to build. A polished MVP for most businesses costs $40,000 to $120,000, and a lean single-workflow one $5,000 to $30,000. Our week-by-week MVP timeline and the breakdown of what an MVP costs and why go through both, so I won't repeat them here.

What an MVP can't tell you is whether the architecture holds at a hundred times the users, or what the full product should look like in two years. It tells you what to build next.

Which should you build first?

Build first whichever one tests the assumption most likely to kill the idea. Technical risk calls for a POC, usability risk for a prototype, and demand risk for an MVP or an even cheaper demand test.

List your assumptions and ask of each one: if this is false, is the idea dead? Then go through them in this order:

1. Could the hard part be impossible, or too expensive to run? Build a POC first, and don't design screens until it passes.
2. Is the core interaction new, complicated or easy to get wrong? Prototype it and test it with five people before anyone writes production code.
3. Do you have evidence people will pay, such as pre-orders or customers already paying for a worse fix? If not, the MVP is your test, so scope it around one workflow.
4. If you already have that evidence, you're past the MVP question. Plan the product properly.

(opens the full-size chart in a new tab)

In practice, most ideas skip at least one step. Say you're building a booking tool for physiotherapy clinics. There are no technical unknowns, so it goes prototype, then MVP. A product built on a speech-to-text model might need a POC on accuracy with strong regional accents before anyone draws a screen. Few ideas need all three in a row.

The mistake I'd warn against hardest is building an MVP to answer a technical question. If the core mechanism fails in week nine, you've paid for eight weeks of sign-up screens around something that doesn't work.

How long does each one take compared with the others?

A clickable prototype takes days to 2 weeks and a well-scoped MVP takes 6 to 14 weeks, by our estimates. A POC should be sized to its one question. In our view that's usually days to a few weeks, and if it runs longer, the question is too big.

(opens the full-size chart in a new tab)

The gap matters more than the exact figures. Even against the top of our prototype range, 2 weeks, an MVP takes three to seven times as long, and it keeps a bigger team busy the whole time.

Cost follows people times weeks, for all three:

• POC: one or two engineers who know the specific technology, for the length of the test.
• Prototype: a product designer, plus a few hours of your time to recruit testers and sit in on sessions.
• MVP: a full team covering discovery, design, development, QA and project management for 6 to 14 weeks.

We don't publish price ranges for a POC or a prototype, because their size depends on the question. Planning a subscription product? Our SaaS product engineering page shows how we take one from first version to scale.

Is an AI-built app a prototype or an MVP?

An app built with Lovable, Bolt, v0 or a similar tool is usually a high-fidelity prototype that happens to run. It becomes an MVP when strangers can sign up, pay and trust it with their data, and getting there takes an engineering review.

For prototype testing, these tools are a gift. Test users click through real flows on a real database instead of a façade.

The trap is that it looks finished. The happy path works while you watch, so it feels like an MVP. The parts that make software safe for strangers are the parts nobody prompted for: who can read which rows, where the secret keys live, whether a payment is processed exactly once. Our production checklist for AI-built apps shows how to check yours.

My rule is simple. Use the AI-built version freely as your prototype. Before it takes money or personal data, harden it first and add features after.

What should each stage hand over to the next?

Each stage should end with a decision and a short written record. A POC hands over a yes or no with numbers, a prototype hands over tested flows and design files, and an MVP hands over usage data and a list of what to build next.

Agree the exit criteria in writing before you start. Otherwise each stage drifts into the next one and nobody ever decides anything.

• POC exit: the pass mark you set was met or missed. Keep the findings, the test data and notes on what was hard. Throw the code away, or keep it only as a reference.
• Prototype exit: most testers finished the core tasks without help, and the problems they hit are fixed or written down. The design files go to whoever builds the MVP.
• MVP exit: you've hit or clearly missed a usage target agreed in advance, such as weekly active accounts or paid conversions.

(opens the full-size chart in a new tab)

The usual failures, all avoidable:

• POC code shipped as the product. It was written fast to answer one question, with no tests and no security. Rebuild that piece properly in the MVP.
• A prototype polished for months. After two or three rounds of testing, more polish rarely changes what you'd build.
• An MVP with every feature on the list. Each one adds build weeks and blurs the result, because you can't tell which feature people came for.

What's the cheapest test you can run this month?

Write down the one assumption that would sink your idea, then pick the cheapest build that tests it. A technical unknown gets a POC and a confusing flow gets a prototype. A demand question gets an MVP, or something smaller still, like a landing page that takes pre-orders. For a typical web or SaaS idea, that means a quick prototype followed by a tight MVP.

If you'd like a second opinion on which risk is biggest, send us a short brief with the idea and the assumption you're least sure of. We'll tell you which of the three to start with, and we'll say so when the answer is a test you can run without us.