MVP vs prototype: what's the difference, and which do you need first?

A prototype isn't really the opposite of an MVP. Nielsen Norman Group, the usability research firm, treats prototypes as one of two broad formats an MVP can take, the other being live code. So the real choice is less "which one?" and more "which question am I trying to answer first?"

We're a design and development studio, so we build both for a living and we're not neutral: we like to test a prototype first when the risk is usability, and to ship a small MVP when the risk is demand. Where we use our own numbers, they come from our MVP development page and our pricing page. Every outside fact is linked and was read on 3 November 2026.

The short answer

A prototype can teach you a lot in days and almost nothing about retention or revenue. An MVP can teach you a lot, but only if people can use it. Nielsen Norman Group's warning is that without adequate usability, an MVP test "becomes a test of the interface, not of the idea". That's the strongest reason to test a prototype before you build.

What is a prototype?

A prototype is a model of the product that lets someone try it before it exists. Nielsen Norman Group describes a user interface prototype as "a hypothesis", a candidate design that you test by watching people use it. It can be very rough or very close to the real thing:

• Paper or sketch. Hand-drawn screens, shown one at a time. Quick and cheap, and good when you're choosing between several concepts.
• Clickable. Screens linked in a design tool such as Figma, so a tester can tap through a task. Good when you have a clear concept and want to see whether people understand it and find their way.
• Wizard of Oz. The product looks automated, but a person does the work behind the scenes. Nielsen Norman Group points to it for testing intelligent or complex systems that haven't been built yet.

The card above is a finished screen from our Timerack case study, shown as the kind of screen a clickable prototype simulates before anything is built. A prototype doesn't need a back end, real data or an account system. That's the point of it. Nielsen Norman Group's point is that throwing away code is very expensive and throwing away a prototype isn't, least of all when it's a piece of paper.

What is an MVP?

MVP stands for minimum viable product. Nielsen Norman Group defines it as "the simplest version of a product or feature that enables a team to assess whether users will derive meaningful value from that product", and credits Eric Ries's *The Lean Startup* with popularising the term. In Lean Startup's own words, you build an MVP "to begin the process of learning as quickly as possible", then measure and learn.

Three things people get wrong about it:

• It isn't a rough or broken product. "Viable" matters as much as "minimum". It has to work well enough, and be usable enough, for the feedback to mean something.
• It isn't a beta. Maze points out that a beta is what you release once all the features are built and you're still hunting bugs. An MVP is a deliberately small first version.
• It doesn't have to be software. Nielsen Norman Group says MVPs "can take many forms, from paper prototypes to functional features in production". Our guide to MVP design covers the non-software ones, such as landing pages, fake doors and concierge services.

Why you'll find three different definitions of "prototype"

If you've read a few articles on this, you've probably noticed that they don't agree. They're using the same word for different things:

• TheServerSide describes a prototype's goal as "to simply prove the technical feasibility of a concept". That's the engineering meaning.
• UXPin and Hostinger describe it as a simulation of the design, used to test the experience. That's the design meaning.
• Division 77 describes a prototype as quick and throwaway code: shortcuts, hard-coded values, no worry about the interface.

None of them is wrong. They're describing different tools. When someone says "let's build a prototype," ask what they want to learn. If it's "can this be built?", they want a technical test, which others call a proof of concept. If it's "will people understand it?", they want screens. If it's "does the team agree on how it should behave?", a rough working demo does that.

MVP vs prototype: the differences that matter

The time row is where the sources disagree most, so we've kept it as a range and come back to it below.

Adam Fard's agency makes a useful point about commitment. After you've put real time into an MVP, you can't abandon it easily, while starting over on a prototype can be as simple as throwing away a sketch. That difference is why the prototype comes first when you're unsure.

What each one can and can't tell you

This should decide your order.

Nielsen Norman Group lists four questions a prototype can answer:

1. Comprehension. Do people understand what the product can do for them?
2. Usefulness. Do they find it useful for what they need?
3. Expected outcome. Do they take the action you hope for, such as signing up or exploring further?
4. Usability of the core flow. Can they finish the main task without confusion, even in a simplified form?

What a prototype can't give you is behaviour over time. A test session is short and people know they're being watched, so it can't show whether someone comes back next week. For that you need a live version, which Nielsen Norman Group calls a live-code MVP: "a minimal, fully coded experience released to a real audience". It lets you measure engagement, retention, conversions, and how the system performs, such as the share of users who finish onboarding, or who return within seven days of their first session.

An MVP has its own blind spot. If people struggle to use it, you won't know whether they dislike the idea or just couldn't work the interface. The cheapest place to find that out is before the build, with a prototype.

Prototype vs MVP vs proof of concept

Several of the pages that rank for this search bring in a third term, so here's where it fits. A proof of concept, or PoC, answers "can this work?" UXPin separates three kinds: technical (a small piece of working code), business (a market study, landing page test or financial model) and design (a conceptual mockup). It's the one to reach for when the technology itself is the risk, such as a new algorithm or an unproven integration.

UXPin and Hostinger both describe a common order: proof of concept, then prototype, then MVP. UXPin also says you don't always need all three: if the technology is proven, skip the proof of concept, and a team iterating on an existing product might need only prototypes.

Which should you build first?

Work out your riskiest assumption, the thing that, if wrong, makes the whole idea fail. Then pick the cheapest thing that tests it. Nielsen Norman Group's version is a risk and reward check: high-risk, high-reward ideas should be tested first with prototype MVPs, while low-risk, high-reward ideas can go straight to live code.

Use these questions:

1. Is the risk that people won't understand it or can't use it? Build a clickable prototype and test it with a handful of people. Nielsen Norman Group's research on test sizes found the best results come from testing no more than five users and running as many small tests as you can afford.
2. Is the risk that nobody wants it? A prototype can show interest, but real demand needs a real signal: a sign-up, a deposit, a pre-order. A landing page or a manual MVP can test that without building the product.
3. Is the risk technical? Do a proof of concept on the hard part only.
4. Do you already have strong evidence? Nielsen Norman Group notes that strong evidence reduces risk and may make an MVP less necessary. If customers are already asking for exactly this, build.
5. Will the thing be built on? If real people will use it and other people will inherit the code, it's an MVP, not a prototype. Division 77's rule of thumb: nobody wants to inherit someone else's bad code or bad architecture.
6. Who are you showing it to? Investors, a co-founder or your team can usually be convinced by a prototype. Customers' willingness to pay is only convinced by something they can use.

When to skip the prototype

You don't always need one. Adam Fard's team makes the case for a small internal tool: if you could build 90% of it in a week, two days on a prototype and another for sign-off may not be worth it. A single-feature product with a very clear flow can often go straight to a build.

Skip it when the flow is simple, the cost of changing it later is small, and you can put the real thing in front of users quickly. Don't skip it when the product has several roles, payments, health or money data, or flows where being confused would lose users on day one.

When a prototype isn't enough

Stop at a prototype and you'll have a design everyone likes and no evidence of demand. Signs that it's time to build:

• Test users complete the core task without help, in several rounds.
• You can say what real use you'd measure, and what number would count as success.
• You know who the first fifty users are and how you'll reach them.
• The remaining questions can only be answered by live use, such as whether people return.

How the two fit together at Usarion

Here's how it works for us, using numbers from our MVP development page. For most products, scoping takes two to three days, the prototype takes another one to two weeks, and then build and launch take the product to six to ten weeks in total. The prototype is clickable and goes in front of real users while development is still spinning up.

We design and build in one team, which changes the prototype's job. Our MVP page says it plainly: when design and build sit in one team, "a screen that is expensive to build gets simplified while it is still a drawing, not after a developer has spent a week on it". So the prototype doubles as a cost check on the build.

Timerack shows the drawing side. It's time and attendance software for staffing agencies, and the managers who run it need to switch each employee's access on or off. As the Timerack case study puts it, "We drew the employee dashboard in four versions, so people only ever see what they can use." Changing a drawing is cheaper than changing a build, which is why we draw first. We haven't published test numbers from our client prototypes, so we won't quote any here.

Sociarion, one of our own two products, shows what the MVP side looks like. It turns one upload into posts for every account, each in its brand's voice. The first users had it five weeks after we started. To get there fast, the first version asked each user to make their own Telegram bot and paste its key in. As the Sociarion case study says, it was quick to build and enough to prove the loop worked. Then real users showed it was the slowest step in getting started, so everyone now shares Sociarion's own bot and connecting takes one tap.

We can't say a prototype test would have missed it, but live use showed it without anyone having to go looking. A clickable prototype shows whether someone understands a setup screen. It doesn't show that they'll give up at step one when they're busy. That's the kind of lesson a live MVP teaches best, and it's why we ship the smallest working version and let use decide what's next.

Two design decisions in Sociarion protect the first impression. By default, nothing is published until a person approves it (only a brand you trust can post on a timer), and a test mode runs the whole pipeline without posting anything, so a new user can watch it work first. Nielsen Norman Group suggests a similar safeguard for live-code MVPs: show people a preview of what the product will do before asking them to act, especially when money, personal data or automation is involved.

How long they take, and what they cost

The sources give different time ranges, which tells you how much depends on scope:

• UXPin: in its FAQ, a proof of concept takes days to a few weeks, prototypes one to four weeks depending on fidelity, and MVPs one to three months. Its comparison table says "days to weeks" for a prototype and "weeks to months" for an MVP.
• Hostinger: a prototype can be ready "within a few hours to a few days"; an MVP with traditional tools takes weeks to months. Its comparison table says a prototype takes "days to weeks".
• TheServerSide: a prototype might take days or weeks, while an MVP takes months.
• Usarion: scoping two to three days, a clickable prototype one to two weeks, and six to ten weeks for the full MVP of most products we take on.

On cost, none of the pages we read give figures we could check, and we haven't invented any. What we can say is what drives it. A prototype's time depends on how realistic it needs to be; UXPin ties it to fidelity. An MVP's follows everything behind the screens: Hostinger lists data schemas, custom code, API integrations, authentication, deployment and testing. Nielsen Norman Group notes that even a lightweight code MVP needs ongoing support, bug fixes and infrastructure that a prototype doesn't, so an MVP's cost doesn't stop at launch. Our own prices are on the pricing page: fixed-scope projects start from $5,000, quoted against a written scope, and monthly plans run from $2,000 for 40 hours to $8,000 for 200 hours. If you want to compare studios on price and timeline, our list of the best MVP development companies gives each one's own published figures where they have them.

How to build each, briefly

A prototype:

1. Pick the one task a user has to get done.
2. Sketch the screens for it on paper, then link them in a design tool such as Figma.
3. Put real words in, not placeholder text.
4. Put it in front of a handful of people and watch where they stop.
5. Fix the screen where several of them stopped, and test again.

An MVP:

1. Write down the one thing it has to prove and the number that would count as success.
2. Cut everything else from the first version.
3. Build the core flow properly, with the empty, error and loading states.
4. Set up measurement before launch.
5. Release to a small group and watch what they do.

Common mistakes

• A clickable prototype launched as an MVP. There's no product behind it, so nothing can be measured.
• An MVP built with no prototype test. Then the first test is of your interface, not your idea.
• A prototype polished for weeks. Adam Fard's advice is to let target users see it at some point.
• Tests with friends. Friends already know what it's for and don't want to upset you, so it's easy to over-trust what they say.
• "I'd use that" taken as demand. It's a good sign, but only an action such as a sign-up or a payment shows demand.
• A prototype thrown away with no hand-over. Document the flows, the states and the decisions from the prototype so the build keeps them.
• No measurement at launch. Decide before the MVP goes out what you'll count: onboarding completion, return visits, the first paid action.

What to do after the test

If a prototype test goes well, scope the MVP around the one core task, and write down the number that would count as success. If it goes badly, you've saved the cost of a build, and you can change the idea while it's still a drawing.

After an MVP launch, watch behaviour. Nielsen Norman Group suggests measuring engagement, such as the share of users who finish onboarding; retention, such as users who return within seven days; and conversions, such as the share who sign up or upgrade. Then change one thing at a time. If you're building the first version, our MVP design guide goes through the steps from problem to launch.

FAQ

If you're trying to decide between the two, book a call and bring what you have, even if it's a list of flows or a rough idea. We'll tell you what we'd test first, and what our MVP development work would cover.