Should your startup build a proof of concept, a prototype or an MVP first?

Say you have an idea, maybe a demo, and you are talking to development companies. One suggests a proof of concept, another a prototype, a third an MVP, a minimum viable product. Each answers a different question.

If you doubt that one technical part can work, build a proof of concept: a small working version of just that part. If you doubt that people will understand the product, build a prototype, a model they can click through. If both are clear, build the MVP, the first version real users can use.

When the choice is less clear, the one-page template further down helps you decide.

What is the difference between a proof of concept (PoC), a prototype and an MVP?

Each one answers its own question, for its own audience.

A proof of concept tests the one part your idea depends on, such as a payment flow, a data import or an AI answer that must be right. It can look rough, because its only job is to show that this part works.

A prototype shows the product to people before there is much of a real system behind it: clickable screens, or sketches on paper. The Nielsen Norman Group (NN/g), a user-experience research firm, calls a prototype a hypothesis, a candidate design you test by watching people use it.

An MVP is the first version that real users use for the job it promises. The term caught on after Eric Ries described it in his book The Lean Startup. He defines an MVP as the version that lets a team learn the most about its customers for the least effort.

Which one should you build first?

Build first whatever answers the question that could end your project, and skip a stage whose question already has an answer.

A technical part might not work. Build a proof of concept of that part alone. It has done its job when the risky part works on real input and you can state the result in one sentence.

You are not sure people understand the flow. A prototype is enough. Give it to someone who has never seen it, name the main task, then watch rather than talk, as NN/g advises. For an AI product, try a Wizard of Oz test: a person plays the AI's part behind the scenes before any AI is built, a method NN/g describes. You have your answer once a newcomer finishes the main task alone, or once you see exactly where they stop.

Both are clear. Build the MVP: one main flow, the admin tools to run it and the analytics that show whether it works. After launch, read its analytics to see whether people use it for the job it promises.

Both are unclear. Start with the technical part. A prototype of something that cannot be built tests nothing you can use.

You already have a demo. Treat it as your prototype. Watch someone new use it to answer the flow question, then go to the technical one.

Four of our projects show where a first build led.

The full stories are in our case studies of the crypto exchange service for Swipelux and Levee's hotel operations platform.

Our MVP development page lays out the stages from proof of concept to production, each answering one question before you pay for the next. An MVP takes us from 2 days to a few weeks, depending on complexity, and it can be a mobile app, a web app, a desktop app or a Chrome extension.

Do you need all three?

No. Skip any stage whose question already has an answer, and keep each one small. An MVP may be no more than a landing page, or a service that looks automated but is run by hand; the Agile Alliance glossary counts both.

Ries tells of his team spending two weeks on a feature nobody wanted, when a simple AdWords smoke test would have shown it far sooner. So before you pay for any build, ask whether a page, a form or a manual service would answer your question.

Small has a floor, though: an MVP too thin to show whether customers will use it is a pitfall the same glossary names.

Why does "MVP" mean different things to different people?

The term is used for very different builds. Marty Cagan of the Silicon Valley Product Group wrote in 2011 that it covers anything from the smallest experiment to a product vision made real. So two quotes for "an MVP" can describe different work. Ask which of these a company means.

Write down which one you need before you compare quotes, and ask each company to quote exactly that.

What if your prototype already looks finished?

A polished prototype looks like live software, and that makes it tempting to launch. NN/g warns that a polished design makes it easy for an executive to say "this looks good, let's make it go live now". Your prototype may have come from another team or from an AI coding tool such as Cursor, Lovable or Claude Code. Either way, find out what can stay and what has to be rebuilt before paying users arrive.

Levee, in the table above, shows what can follow: its basic prototype needed a production-ready platform, so we rebuilt its backend from scratch.

Check five things before you treat a demo as a product:

• tests that really run, on every change;
• a deployment you can repeat, with secrets kept out of the code;
• access to data checked for each user on the server, not only hidden in the interface;
• error tracking and logs, so you see a failure before a user reports it;
• a clear decision on the parts that are cheaper to rebuild than to fix.

Ask whoever built the demo to show you each one on screen. Anything nobody can show goes on the list to fix before launch. Our guide on how to check a vibe-coded app walks through a 60-minute review you can do yourself.

How much security does an MVP need?

Enough for the real people who use it. If they sign up or pay, plan security into the first version, as we do on our MVPs.

Our four levels of security checks sort the checks by who can open the app, what data it holds and whether money moves. Before the build starts, mark every screen where a user types personal data or pays. Then ask the team who will see that data and how they will check it.

What must your first build prove? Check it today

Fill in this page before your next call with a development team, and send it with your brief.

WHAT COULD END THIS PROJECT (ONE SENTENCE):
DOES THE RISKY TECHNICAL PART WORK? YES / NO / NOT KNOWN
DO PEOPLE UNDERSTAND THE MAIN FLOW? YES / NO / NOT KNOWN
FIRST BUILD: PROOF OF CONCEPT / PROTOTYPE / MVP / A PAGE OR A MANUAL SERVICE
WHO USES IT: OUR TEAM / TEST USERS / REAL CUSTOMERS
REAL PERSONAL OR PAYMENT DATA IN IT: YES / NO
PLATFORM: WEB / MOBILE / DESKTOP / BROWSER EXTENSION
RESULT THAT MEANS GO ON:
RESULT THAT MEANS STOP OR CHANGE:
WHAT HAPPENS TO THE CODE AFTERWARDS: THROW AWAY / MAKE READY FOR PRODUCTION / KEEP AND GROW

Lines 2 and 3 pick the first build. A "no" or "not known" on the technical part points to a proof of concept. The same answer on the flow points to a prototype, and two "yes" answers point to the MVP. If both lines say "not known", start with the technical part.

Without an engineer of your own, answer line 2 by asking whoever will build it to show the risky part working on real input. Until they do, the answer stays NOT KNOWN.

Say you plan a booking app for hair salons and have a demo made with an AI tool. The risk that could end it is taking deposits for bookings. Suppose the people who tried the demo booked without help: line 3 is yes. Suppose nobody has taken a deposit through it yet: line 2 is not known. The first build is a proof of concept of deposits, with test payments only.

Going on, in this example, means a test deposit reaches the salon's account; stopping or changing means it cannot.

What are the limits of this choice?

The template decides what to build first, not who builds it; for that, our guide on choosing a development company shows what you can check before you sign. It does not replace talking to customers either, so plan time for those conversations and for reading the analytics. And the choice comes back after launch: whatever the first build shows should change the next one.

Next step

Sources

• Eric Ries, What is an MVP?, Lean Startup Co., first published on his blog Startup Lessons Learned
• Marty Cagan, Minimum Viable Product, Silicon Valley Product Group, 24 August 2011
• Kara Pernice, UX Prototypes: Low Fidelity vs. High Fidelity, Nielsen Norman Group, 18 December 2016
• Agile Alliance glossary, Minimum Viable Product (MVP)