MVP vs prototype vs proof of concept: what's the difference?

MVP vs prototype comes down to the question each answers. A prototype tests if people understand a product, a proof of concept tests if the technology works, and an MVP tests if real users will use it and pay. UK agencies charge £10,000 to £25,000 for an MVP in 2026 (Magora). iHux: 14 working days; one platform, one core flow; fixed £7,500 for projects booked by 28 Feb 2027, then £9,500.

The terms get mixed up, and the mix-up costs money. Founders build an MVP when a prototype would have answered their question, or show investors a prototype and call it a product. This post sets out what each one proves and how to pick.

What is a prototype?

A prototype is a model of the product. It is usually a set of designed screens linked together, so you can tap from one to the next as if the app worked. Nothing happens behind the screens: no real data, no real account, no server.

That is its strength. A clickable prototype is quick to make and cheap to throw away. You can put it in front of ten people, watch where they get stuck, and change the design the same afternoon.

A prototype answers questions like these:

• Do people understand what the product does?
• Can they find the main action without help?
• Does the idea make sense to an investor or a partner?

It can't tell you whether people will come back, pay or trust you with their data. For that, the product has to work.

What is a proof of concept?

A proof of concept is a narrow technical test of one risky part. Magora (2026) frames it as answering "can the technology do it?". If your idea depends on a data source, a device feature or an integration that might not work, test that before you design around it. A proof of concept has no users and often no screens.

What is an MVP?

An MVP, a minimum viable product, is the smallest version of your product that real users can use for real. It runs on real code. Accounts, data and the core flow all work. It can go on the App Store or the web.

An MVP answers the questions a prototype can't:

• Will people sign up and finish the core flow?
• Do they come back?
• Will they pay?

Because it is real software, the code matters. A good MVP is built so the next version can sit on top of it. A bad one falls over when real users arrive and has to be rewritten.

MVP vs prototype vs POC: the difference in one table

Magora's free prototype is an agency's entry offer, so read it as a starting price, not a market rate. In the US, Empat (2026) says a coded, single-feature MVP starts at about $30,000 and takes 6 to 12 weeks. Our post on what it costs to build an MVP compares more quotes.

Prototype vs MVP: which do you need?

Start with your riskiest question, and build the cheapest thing that answers it.

Build a prototype if:

• You aren't sure people understand the idea yet.
• You need something to show investors or partners before you spend on a build.
• You are choosing between two or three designs.

Run a proof of concept if:

• The whole product depends on one technical piece you aren't sure works.

Build an MVP if:

• You know people get the idea, and now need to know if they will use it.
• You want real numbers: sign-ups, return visits, payments.
• You plan to keep building on the first version if it works.

You don't always need all three. If the technology is proven and the flow is simple, you can go straight to an MVP that starts with design.

iHux can deliver a clickable prototype on its own: an interactive design of your product, not wired to a backend or real data. It is quoted per project. Tell us what you need, or see our UI/UX design service.

Working prototype vs MVP: where is the line?

A common question is "my prototype already has code: is it an MVP?" Code alone doesn't make it one. Three things do:

1. Real users, not testers you invited to watch.
2. Real data, stored safely, with accounts that only show each user their own.
3. Reviewed code that the next version can be built on.

A working prototype built fast, often with AI tools, usually has the first and misses the other two. It handles the path where everything goes right. Real users bring slow networks, empty fields and expired sessions. Our review step is described in Engineered, not generated.

A pilot is a different thing again: a product, often an MVP, run with one group of users or one customer for a set time before a wider launch.

How a 14-day MVP includes the design step

Our MVP starts with design, so you see and approve the product before code is written:

• Day 1: three design directions for your core flow. You pick one.
• Day 3: you approve the designs. This is the prototype moment, and the last cheap point to change your mind.
• Day 7: a working build to try on your phone.
• Day 11: a senior engineer who didn't build it reviews the code and writes a security report.
• Days 12 and 13: everything the review found is fixed, and the product is polished for handover.
• Day 14: you get the code, the security report and a handover.

Once you have paid for the design stage, you can have the approved designs as a clickable file. It isn't wired to any code, but you can put it in front of testers or investors.

The code is yours from the first commit, in your own accounts, with 7 days of bug fixes after delivery. You pay a deposit at kickoff and the rest on delivery. The 14-day MVP playbook covers each day. Interior AI, one of our own apps, started as an MVP, and our post on design systems for startups covers how much design a first version needs.

See the scope and price on the MVP development page.