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

• A prototype shows how a product would look and work, so you can test ideas with people. It usually isn’t a working product.
• A proof of concept tests whether something is technically possible.
• An MVP (minimum viable product) is a real, working first version that real users can use, so you can learn whether they want it.

Each answers a different question. Picking the wrong one wastes time and money.

A prototype answers: does this make sense to people, and can they use it?

It can be anything from paper sketches to a clickable Figma prototype that looks real. Prototypes are fast and cheap to change, so they’re ideal for:

• Testing your core flow with five or so potential users.
• Comparing two approaches.
• Showing investors or partners what you mean.
• Getting the design right before paying for development.

On OJO, I took the design from paper sketches to a clickable high-fidelity prototype and ran two rounds of usability testing before anything would be built. Testing showed a 0.8-second dwell time caused accidental triggers, so it changed to 1.5 seconds. That was a cheap fix in a prototype and would have been expensive in code.

A proof of concept answers: can this be built?

Use one when there’s real technical uncertainty: a new integration, an unusual use of AI, hardware, or performance limits. It’s usually rough, internal and thrown away once the question is answered.

Many products don’t need one. If you’re building a booking app or a dashboard, the technology is well proven; the risk is whether people want it.

An MVP answers: will people actually use this, and pay for it?

It’s a real product, but deliberately small: the minimum needed to deliver the core value and learn from real behaviour. A good MVP:

• Solves one problem well for one type of user.
• Works reliably, even if it’s not feature-complete.
• Lets you measure whether people come back.

Our guide on how long it takes to build an MVP covers timelines in detail.

• You have an idea and want feedback: start with a prototype.
• You’re unsure the technology can work: do a proof of concept for that part only.
• You’ve tested the design and want real users: build the MVP.
• You need investment: a tested prototype is often enough to show your thinking; an MVP with real usage is stronger.

The usual order is prototype, then MVP, with a proof of concept only where needed.

• Skipping the prototype and discovering usability problems after development.
• Calling a full product an MVP and spending months building features nobody asked for.
• Making an MVP too minimal so it doesn’t actually solve the problem, then concluding nobody wants it.
• Not defining what you want to learn before building.

Write down the one question each stage should answer, and how you’ll know the answer.

A tested prototype makes development faster and cheaper, because the decisions are already made: screens, flows, edge cases and content. Developers build what’s been validated instead of guessing.

My UX/UI design service covers prototypes from £995, and MVP design & development starts at £4,995 for a focused first version. If you’re not sure which you need, start a project brief and I’ll recommend a route.

Imagine a founder with an idea for an app that helps security guards track shifts across several employers:

• Prototype: a clickable Figma prototype of “log a shift” and “see what you’re owed”, tested with five guards. Testing shows the form is too long, so it’s cut down.
• Proof of concept: not needed. Saving shifts and calculating pay is well-proven technology.
• MVP: a mobile-first web app with shift logging, payment status and a simple dashboard, launched to real users.

Shiftaan followed a similar path: it started as my own spreadsheet, was designed in Figma, and launched as a live web app.

List every feature you’ve imagined, then ask of each one: does the product fail to deliver its core value without this? If the answer is no, it waits.

Then check the MVP still feels complete for its one job. Users forgive missing extras. They don’t forgive a core task that doesn’t work.

Once real people use your MVP, the work shifts to learning: what they use, what they ignore, where they get stuck and whether they come back. Those answers decide what you build next, which is why a small, focused MVP gets you to the right product faster than a big one.

Every product is different, but the relative effort usually follows the same pattern:

• Prototype: the smallest investment. Weeks rather than months, and changes are cheap.
• Proof of concept: depends entirely on the technical question. Keep it narrow and time-boxed.
• MVP: the biggest step, because it involves design, development, testing and launch.

Spending a little more time on the prototype usually saves money on the MVP, because fewer decisions change once development starts. Plan your budget so that you still have something left after launch, for fixes and the improvements your first users will ask for.

• A prototype tests whether an idea makes sense and is usable.
• A proof of concept tests whether something can be built.
• An MVP tests whether people will use it and pay for it.
• Test a prototype before building, to save money and time.
• Keep the MVP focused on one core job, and learn from real use.