Proof of concept vs prototype: what should you build first?

A proof of concept, a prototype, and an MVP answer three different questions. Pay to build the wrong one and you spend weeks proving something you already knew.

A founder came to us last year with a signed quote for a “prototype” of his logistics app: forty thousand dollars, a clickable version of every screen. What actually kept him up at night was whether the app could pull live data from three carriers whose systems nobody at his company had touched. That is not a prototype question. He was about to pay to find out his screens looked nice, while the one thing that could kill the company stayed untested.

That is the whole trap of proof of concept vs prototype. A proof of concept answers one question: can this actually be built? A prototype answers a different one: does this feel right to the person who has to use it? An MVP answers a third: will anyone pay for it? Three artifacts, three risks, and they are not three sizes of the same thing. The founder’s real job is to spend money only on the question they can’t already answer. If you know the tech is trivial, a proof of concept is a waste. If you know people want it and you know it’s buildable, skip both and build the thing.

Here is how to tell them apart, and how to decide which one your money should go to first.

What a proof of concept actually proves

A proof of concept is a throwaway experiment that tests whether a specific technical risk can be solved. Not the whole product. The one part that makes you nervous.

The logistics founder’s real proof of concept was two weeks of one engineer trying to authenticate against those three carrier APIs and normalize their data into a single feed. Ugly script, no interface, no login screen, nothing a customer would ever see. The output was a yes or a no. It came back “yes for two of them, and the third needs a paid enterprise tier.” That answer was worth more than the forty-thousand-dollar clickable version, because it changed the pricing model of the entire business before a line of real product got written.

A proof of concept is right when your biggest unknown is a sentence that starts with “can we even.” Can we even sync with that hospital’s records system. Can we even run this matching algorithm fast enough to feel instant. Can we even get an AI model to extract the right fields from a messy PDF reliably. When the risk is technical feasibility, nothing else you build matters until that question has an answer, because a beautiful product on top of an impossible integration is just an expensive way to learn the integration was impossible.

What a proof of concept is not: it is not the first version of your product. You throw it away. Reusing proof-of-concept code as your foundation is one of the more expensive mistakes we see, because that code was written to answer a question fast, not to be maintained by a team for three years.

What a prototype actually proves

A prototype tests whether the thing feels right before anyone builds it for real. The risk it retires is not “can this be built” but “is this the right shape for the person using it.”

Most prototypes are not code at all. They are clickable screens, made in a design tool, that let a real user tap through a flow and get confused in front of you. The value is entirely in watching that confusion happen while changing a screen still costs an afternoon instead of a sprint. If you have ever sat behind someone using your product and felt your stomach drop as they completely missed the button you were proud of, you understand what a prototype is for. It moves that stomach-drop from after launch to before you paid to build.

Prototypes come in fidelities, and the word gets used for all of them, which is part of the confusion. A paper sketch is a prototype. A gray-box wireframe is a prototype. A pixel-perfect, tappable mockup that looks exactly like the finished app is a prototype. They sit on a spectrum from “rough enough to test the flow” to “polished enough to test the feel,” and the more polished ones start to blur into the design work you’d do anyway. We wrote about where that line sits in our piece on wireframes versus mockups; the short version is that a wireframe tests the plumbing and a mockup tests the paint.

A prototype is right when your biggest unknown is about people, not machines. Will they understand the flow. Will they trust it enough to enter their card. Does the onboarding make sense to someone who isn’t you. When the tech is boring and well-trodden but the experience is unproven, that’s a prototype’s job.

Where the MVP comes in, and why the three blur together

The third word founders reach for is MVP, and it belongs in this conversation because it answers the risk the other two don’t touch: will the market actually pay.

A proof of concept proves it can be built. A prototype proves it feels right. Neither proves anyone wants it enough to open their wallet. That’s the minimum viable product’s job, and it’s the risk Steve Blank’s customer development work puts at the center of everything: an MVP has to be real, functioning software that real customers use with real money or real data on the line. A clickable prototype can’t validate demand, because nobody’s stakes are on the table when they tap through a demo. We’ve made the case that most things founders call MVPs are too small to prove anything in our breakdown of the minimum viable product, and that demand question is exactly what a proper market validation effort is built to answer.

The three blur together because they can overlap in a single build, and because vendors have an incentive to keep the words vague. If the same two-week experiment proves the integration works and gets shown to three customers who say “I’d pay for that,” it did the work of a proof of concept and a scrappy validation at once. That’s fine. The point is not to run three separate projects in a rigid sequence. The point is to know which risk each hour of spend is actually buying down, so you don’t pay a designer to polish screens when your real problem is a database you’re not sure exists.

Proof of concept vs prototype: what comes first?

The honest answer: whichever one attacks your biggest unknown. There is no universal order, and any vendor who gives you one without asking about your risk is selling a process, not thinking about your company.

That said, there’s a useful default. When a project carries real technical risk, the proof of concept comes first, because there is no point testing whether users love a flow that can’t be built. Feasibility gates everything. When the tech is ordinary (another CRUD app, another marketplace, another dashboard) and the risk lives entirely in whether people will use and pay, you can skip the proof of concept and start with a prototype, then go straight to an MVP.

The failure we see most often is founders running the order backwards out of enthusiasm. The prototype is the fun part. It’s visual, it’s shareable, it makes the idea feel real, and you can show it to your spouse. So founders spend on the prototype first, fall in love with it, and only discover the feasibility problem months later when an engineer finally tries to build the hard part. By then there’s a beautiful design everyone is attached to and a technical wall nobody checked for. Order your spending by risk, not by what’s satisfying to look at.

The one-question test for deciding what to pay for

Here’s the framework we walk founders through. It takes about five minutes and it’s just one question, asked honestly.

Write down the single thing most likely to kill this project. Not a list. One sentence. Then read which word it starts with.

• If it starts with “can we build”: that’s technical risk. Pay for a proof of concept.
• If it starts with “will people understand, trust, or use it”: that’s design risk. Pay for a prototype.
• If it starts with “will anyone pay, is the market there”: that’s market risk. Pay for an MVP, or cheaper validation before you build anything.
• If you can’t honestly write one sentence, you don’t have a spending decision yet. You have thinking to do.

The discipline is refusing to spend on a risk you’ve already retired. If you’ve integrated with that payment provider on three past projects, “can we build the payments” is not your risk, and a proof of concept for it is theater. If ten customers are already begging you for this and paying competitors for a worse version, “will anyone pay” is answered, and running a long validation is procrastination dressed as rigor.

The rule of thumb: build a proof of concept only when your biggest risk is “can this be built,” a prototype only when it’s “will they use it,” and if you already know both answers, stop testing and build the real thing. Eric Ries put the underlying goal well in The Lean Startup: “The only way to win is to learn faster than anyone else.” Every one of these artifacts is just a way to buy a specific piece of learning cheaply. If it isn’t buying learning you don’t already have, it isn’t cheap. It’s a bill.

Can a prototype be a proof of concept?

Sometimes, and this is where the words genuinely overlap. A prototype can double as a proof of concept when the risky part is the interaction itself, not the plumbing behind it.

Say your bet is a radically simpler way to file an expense report, one gesture instead of a form. Building a working version of that gesture and putting it in front of users tests both feasibility (“can we make this interaction work smoothly”) and desirability (“do people actually prefer it”). One artifact, two risks retired. But the reverse rarely holds: a proof of concept is almost never a prototype, because a POC is usually a headless script with no interface for anyone to react to. It proves the engine turns over. It says nothing about whether anyone wants to drive the car.

The trap is assuming the overlap always exists. Most of the time it doesn’t. Most technical risks live in the backend, invisible, and most usability risks live in the frontend, and testing one tells you nothing about the other. Assume they’re separate until you can clearly explain why, in your specific case, they’re the same.

What each one should cost you, in weeks not features

Founders ask what these cost, and the useful answer is in time and scope, not a dollar figure, because the dollar figure is just the time multiplied by a rate you can look up in our breakdown of what an app actually costs.

A proof of concept should be small and fast: days to two or three weeks, one engineer, one question. If someone quotes you two months for a proof of concept, they’re either testing too many things at once or quietly building your product and calling it a POC. Push back. A proof of concept that takes two months has stopped being a proof of concept.

A prototype scales with fidelity. A rough clickable flow to test a single journey is a few days of design work. A polished, full-app mockup is several weeks, and at that point you should ask whether you’re prototyping or just doing the design phase of the real build early, which is often fine as long as you know that’s what you’re paying for.

An MVP is the expensive one, because it’s real software, and its cost is a whole conversation of its own. The mistake is letting an MVP masquerade as a prototype in a quote, or a prototype masquerade as an MVP. When the number feels too big for the word, the word is usually wrong.

The mistake that burns the most money

The single most expensive error is the one the logistics founder almost made: paying to retire the risk you don’t have while ignoring the one you do. A gorgeous prototype of an app whose core integration turns out to be impossible. A rock-solid proof of concept for a technically hard product nobody actually wants. A full MVP built before anyone checked whether the hard part could be built at all.

The reason this keeps happening is that the fun risk and the real risk are usually different risks. The fun one is visual and shareable. The real one is often boring, buried in a backend, or sitting in an uncomfortable question about whether customers care. Vendors, understandably, would rather sell you the fun one. Your defense is the one-question test and the willingness to spend your first dollar on the unknown that actually scares you, even when it’s the least photogenic part of the whole idea. That’s the difference between a partner and a black box: a partner asks which risk you’re buying down before they quote you, and steers you off the expensive-but-satisfying answer when it’s wrong.

FAQ

What is the difference between a proof of concept and a prototype?
A proof of concept tests whether something can be built (technical feasibility). A prototype tests whether it feels right to use (design and usability). A POC is usually a throwaway script with no interface; a prototype is usually clickable screens with no working backend. They retire different risks and are rarely interchangeable.

What comes first, a proof of concept or a prototype?
Whichever attacks your biggest unknown. As a default, when a project has real technical risk the proof of concept comes first, because there’s no point testing whether users like a flow that can’t be built. When the technology is ordinary and the risk is all about adoption, you can skip the POC and start with a prototype.

What is an example of a proof of concept?
A two-week experiment where one engineer writes an ugly script to test whether your app can authenticate against three external systems and merge their data into one feed. No login, no design, no product. The output is a yes or no on the one technical question that could kill the project.

Can a prototype be a proof of concept?
Yes, when the risky part is the interaction itself rather than the backend. Building and testing a novel gesture proves both that it works and that people want it. But a proof of concept is almost never a prototype, because most POCs have no interface for anyone to react to.

Where does an MVP fit versus a POC and a prototype?
An MVP is real, working software that real customers use, and it answers the market risk the other two can’t: will anyone pay. A proof of concept proves it can be built; a prototype proves it feels right; an MVP proves the business works. Most things founders call an MVP are actually prototypes or scoped-down first versions.