POC, Prototype, MVP or Pilot? What to Build First

Somewhere in the last month, someone in your company said "let's just build a quick MVP" and someone else nodded, and the two of them were picturing completely different things. One meant a rough sketch to show the board. The other meant a real product that early customers pay for. They agreed on the word and disagreed on the work, which is how a two-week job turns into a two-quarter one.

POC, prototype, MVP and pilot are not synonyms for "a smaller version." Each one answers a different question, costs a different amount, and fails in a different way when you pick the wrong one. A proof of concept asks "is this even possible?" A prototype asks "does this feel right?" An MVP asks "will anyone use and pay for this?" A pilot asks "does this hold up in the real operation?" Build the wrong one first and you spend money proving something nobody was worried about, while the actual risk sits untouched. This is a plain guide to what each stage is for, what it should cost, and how to choose the one your project needs right now.

The four stages, and the question each one answers

The useful way to tell these apart is not by size. It is by the risk they retire. Every project carries a stack of unknowns, and you build the cheapest thing that removes the scariest one first.

Read that column on the right carefully. A POC and a prototype are meant to be thrown away, and treating them as the first version of production code is one of the most expensive mistakes in software. An MVP and a pilot are the opposite: they are the real thing at small scale, and they carry the code and the users forward.

Proof of concept: does the hard part work at all?

A POC exists to kill technical doubt. You reach for one when a project depends on something you are genuinely not sure is achievable: can we hit this latency, can this model reach usable accuracy on our messy data, will this legacy system let us integrate at all, can we process this volume without the costs exploding.

It is narrow on purpose. No design, no login screen, no polish. A script and a result. The output is not a product, it is an answer: yes it works, here are the numbers, or no, and here is the wall we hit. A good POC saves you from building a beautiful product on top of an assumption that was never true.

Skip the POC when nothing about the build is technically uncertain. Most CRUD apps, marketing sites, and standard integrations do not need one, because the answer to "is this possible?" is obviously yes. Spending a sprint proving the obvious is its own kind of waste.

Prototype: does the experience make sense before you build it?

A prototype is about the how, not the whether. It looks real and does almost nothing, a clickable set of screens in Figma or a thin front end with fake data, built so people can react to something concrete instead of a description in a document.

Its job is to surface the disagreements early, while they cost a coffee to fix instead of a rebuild. Users click through and you learn that the flow everyone approved on a whiteboard makes no sense in practice. Stakeholders see the actual screens and discover they meant different things by the same requirement. That feedback is cheap here and brutally expensive after the code exists.

Prototypes are throwaway by design, and that is a feature. Because nothing behind them is real, you can try three versions of a flow in the time it would take to build one for real. The trap is falling in love with the polish and asking the team to "just wire it up." A prototype with no working data, no edge cases, and no persistence is not almost-done. It is a picture.

MVP: the smallest thing real customers actually use

This is the term everyone abuses. An MVP is not a cheap product or a broken product. It is the smallest complete product that delivers real value to real users and lets you learn from what they do with it. The key words are complete and real. It is live, people rely on it, and it goes forward from here.

Minimum means ruthless scope, not low quality. You cut features, not corners. One workflow done properly beats ten done badly, because the point is to put a real thing in front of real users and watch. Do they come back? Do they pay? Which feature do they beg for? An MVP that nobody uses has still done its job, it told you the truth before you spent the full budget. We break the money side down in what a SaaS MVP costs to build, and the scoping discipline in how to scope a custom software project.

Pilot: does it hold up in the real operation?

A pilot is the step people forget, and it is often the one that matters most for anything sold into a business. You have a working product. The open question is whether it survives contact with a real team, real data, real edge cases, and the messy way people actually work. So you run it live with one client, one branch, or one department, at limited scale, with a way to fall back if it breaks.

The difference between a pilot and an MVP is the setting. An MVP tests whether the product is wanted. A pilot tests whether the product works inside a specific operation before you roll it out to everyone. It is where you find the exception nobody mentioned, the integration that behaves differently under load, and the training gap that no demo revealed. For AI projects especially, the pilot is where value is won or lost, which we cover in AI agent ROI from pilot to payback and why so many AI pilots stall.

How to choose the one you need first

Skip the vocabulary argument and ask what you are actually unsure about. The right first build is the one that removes your biggest doubt for the least money.

• Not sure it is technically possible? Start with a POC. Retire the technical risk before you spend a cent on design.
• Not sure the experience or the flow is right? Start with a prototype. Get people clicking before anyone writes production code.
• Not sure anyone wants it or will pay? Build an MVP. Put a real, small, working product in front of real users.
• Sure people want it, unsure it survives real operations? Run a pilot. Prove it in one live setting before rolling out wide.

Most real projects move through more than one of these, but rarely all four, and almost never in a rigid line. An internal tool with no market risk may skip straight to a pilot. A moonshot with heavy technical doubt starts with a POC and a prototype in parallel. The skill is naming your biggest unknown honestly, because that is the stage you actually need, whatever the person across the table is calling it.

If you and your team keep using these four words to mean different things, that is usually a sign the real risk has not been named yet. Tell us what you are trying to build and we will help you figure out which of these to build first, and just as usefully, which ones you can skip. For the wider decision of whether to build at all, build versus buy is the companion piece.