TL;DR
A proof of concept answers “can this be built at all”. It is code with no interface, judged by engineers, and it is a success even when the answer is no.
A prototype answers “would anyone use this”. It is an interface with no working code, judged by users and stakeholders, and it is a success when somebody tries to do something you did not design for.
They are not two sizes of the same thing. They de-risk opposite ends of the product. Buying the wrong one costs you the four to six weeks you spent answering a question you were not actually worried about.
If your biggest unknown is technical, you need a PoC. If it is human, you need a prototype. Most founders need one of them, not both, and the ones who need both should run them in that order.
PoC vs prototype at a glance
| Proof of concept | Prototype | |
|---|---|---|
| Question it answers | Can this be built? | Would anyone use this? |
| Type of risk removed | Technical | Market and usability |
| Who judges it | Engineers and architects | Real users and stakeholders |
| What actually exists | Working code, little or no UI | UI, no working backend |
| Data | Sample, synthetic or a copied slice | Fake, hard coded, illustrative |
| Typical length | 2 to 4 weeks | 1 to 3 weeks |
| Typical cost | $8k to $30k | $4k to $20k |
| Who builds it | Backend or ML engineers | Product designers |
| Output | A written technical verdict | Evidence about user behaviour |
| Success looks like | A confident yes or no | Watching someone misuse it |
| Is the work kept? | Usually not, and that is fine | Yes, the design carries forward |
| Shown to investors? | Rarely, it looks like nothing | Often, it demos well |
The row that surprises people is the last one. A prototype demos beautifully and proves nothing about whether the thing can be built. A PoC proves the hard part and looks like a terminal window. Founders who pick based on what they can show a room end up with the wrong artefact.
What a proof of concept actually is
A PoC exists to remove one specific technical doubt. The discipline is in the word *one*, and good PoCs look unimpressive to anyone who was not in the room when the question was framed.
The one-question rule
If you cannot write the unknown as a single question with a yes or no answer, the scope is not ready yet. Well-formed PoC questions look like this:
- Can we extract structured data from these particular supplier invoices at an accuracy the finance team will accept?
- Will this legacy system let us read the records we need without a vendor contract we cannot get?
- Can the model run inside our latency budget on hardware we can afford?
- Can these two systems be reconciled, given neither has a stable identifier for the same customer?
- Does this API return the fields the process actually needs, or only the fields the documentation advertises?
Notice what none of them mention: interface, design, onboarding, pricing, or what the product will feel like. Those are prototype questions.
What a PoC looks like when it is done properly
Usually a script, a notebook, or a small service with no front end at all. Sometimes a spreadsheet of results next to a two page memo.
The deliverable is the memo. It says what was tested, on what data, what the result was, what it cost, and what the team is now confident about that they were not confident about four weeks ago.
Why a PoC that says no is a success
This is the part founders find hardest, and it is the entire economic argument for running one.
A PoC that returns a clear no has just saved you the cost of the build. If the answer arrives in week three for $14,000 instead of in month five for $90,000, the PoC did its job perfectly. Any vendor who cannot say no to you at the end of a PoC is not running a PoC, they are running a sales process.
What a PoC is deliberately not
It is not production code, and it should not be. PoC code is written to answer a question fast, which means shortcuts that are correct for a PoC and wrong for a product: no error handling, no tests, credentials in a config file, no thought about scale.
It is also not a demo. If somebody promises a proof of concept that will also impress investors and become your production codebase, you are being sold three things at the price of one, and you will get none of them properly.
We covered the neighbouring distinction, PoC against a live operational trial, in PoC vs pilot.
What a prototype actually is
A prototype exists to put something in front of a human before you build it. It simulates the experience of the product without any of the machinery behind it.
The two kinds, and people mean different ones
Half the confusion in this comparison comes from the word prototype covering two very different artefacts.
Low fidelity. Sketches, wireframes, grey boxes. Cheap, fast, and designed to be thrown away in the meeting. Good for testing structure: does this flow make sense, is this the right order of steps.
High fidelity. Clickable, styled, looks exactly like a real app, does absolutely nothing underneath. Built in Figma, Framer or similar. Good for testing comprehension and desirability: do people understand what this is, would they sign up.
When a vendor quotes you a prototype, ask which one. The gap between them is several thousand dollars and a completely different conversation.
What is actually inside one
Screens, transitions, and hard coded content. The numbers on the dashboard are typed in. The search returns the same three results every time. The payment step goes to a success screen without touching a payment processor.
That is not a shortcoming. It is the point. Nothing behind the glass means nothing to build, which is why you can have one in a week.
What a prototype is judged on
Not whether people say they like it. People are polite, and a founder in the room makes them politer.
A prototype is judged on what people do: where they hesitate, what they click that you did not expect, what they say the product is for after they have used it, and whether that matches what you think you are building.
The most valuable single output of a prototype test is watching somebody use it wrong. That is a design finding you cannot get from a spec review, and it costs four figures instead of six.
Where a prototype quietly fails
It cannot tell you whether people will pay. Intent expressed in a usability session is a weak signal, and the gap between “I would definitely use this” and a credit card is the widest gap in early-stage product.
It also cannot tell you whether the thing is buildable. A designer can draw a feature in twenty minutes that is eighteen months of engineering, and a prototype gives you no warning at all.
The difference, stated properly
Proof of concept vs prototype, in one sentence
A proof of concept is code that works with no interface. A prototype is an interface that works with no code.
That is the cleanest way to hold the difference in your head, and it is also the fastest way to tell whether a vendor understands what they are quoting you. Everything below is a consequence of that one line.
Different question
A PoC asks whether the machine can work. A prototype asks whether the person wants it. There is no overlap between those two questions, which is why one cannot substitute for the other.
Different audience
A PoC is reviewed by your CTO, a contract architect, or the engineer who will have to own the thing. A prototype is reviewed by five people who look like your customers, in a room, one at a time.
If the same person is the sole judge of both, you are not testing anything.
Different artefact
At the end of a PoC you have a script, a service or a notebook, plus a memo. At the end of a prototype you have screens, a click-through link and a set of recorded sessions.
Neither one can be handed to the other’s audience. A designer cannot review a notebook, and an architect learns nothing from a click-through.
Different definition of done
A PoC is done when the question is answered, including when the answer is no. A prototype is done when you have watched enough people use it to stop being surprised.
Neither is done when it looks finished. That instinct is what turns a two week prototype into a two month one.
PoC vs prototype vs MVP: the three-way version
Most people searching for this comparison are really holding three words, not two, so here is where the third one sits.
Where the MVP sits
An MVP is the smallest version of the real product that real people can use for real. It has working code, a real interface, and real users on real data.
That makes it the only one of the three that can answer a commercial question, and also the only one that can lose you money if it is wrong. We wrote the full definition in what is an MVP, and the two-way comparisons live in MVP vs PoC and MVP vs prototype.
Why these three get conflated
Because vendors sell all three and the words are cheap. “We will build you a prototype” sounds like less commitment than “we will build you an MVP”, so it gets used as a discount label for a small build.
Read the deliverable, not the noun. If the thing being quoted has a database and real users, it is an MVP whatever the proposal calls it.
The order that actually works
There is no fixed sequence, and the idea that everyone climbs PoC to prototype to MVP is the single most expensive misconception in this area.
The order is: whichever question would kill the company soonest, first. For a deep-tech product that is the PoC. For a consumer app in a crowded category that is the prototype. For a founder who already has design partners waiting, it may be neither, and the answer is to go straight to the MVP.
If you want a structured version of that, the MVP type quiz walks the same decision.
What each one costs
Numbers move with scope and seniority, so treat these as the shape of the decision rather than a quote.
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Typical cost | $8k to $30k | $4k to $20k | $25k to $90k |
| Typical duration | 2 to 4 weeks | 1 to 3 weeks | 8 to 16 weeks |
| Who does the work | Backend or ML engineers | Product designers | A full team |
| What drives the price | Difficulty of the unknown | Fidelity and screen count | Number of features |
| What you keep | A memo, usually not the code | Design assets and findings | The product |
What actually drives a PoC price
The difficulty of the question, not the size of the product. A PoC on a gnarly integration with a forty year old system can cost more than a PoC on a machine learning model, because the hard part is access rather than maths.
Anything quoted at twelve weeks is not a PoC. The scope contains more than one question, and it should be split.
What actually drives a prototype price
Fidelity and screen count, in that order. A low fidelity flow of eight screens is a few days. A high fidelity clickable version of the same eight screens with a design system underneath it is two to three weeks.
Ask what happens to the design assets afterwards. If they carry into the build, the prototype is partly an investment. If they get redrawn, it was a pure research cost, which is fine as long as you knew.
The cost of buying the wrong one
This is the real number and nobody puts it in a proposal.
Buy a prototype when your risk was technical, and you spend three weeks and $12,000 learning that people like an idea you cannot build. Buy a PoC when your risk was market, and you spend four weeks proving you can build something nobody asked for.
Both failures cost roughly the same: about a month, plus the round of fundraising you spent it during. For the full picture on build economics, see what an MVP actually costs and the cost calculator. PoC pricing specifically is broken down in proof of concept cost.
Which one you need
The prototype vs PoC decision comes down to a single question, and it is not a question about budget or about which artefact sounds more serious.
It is this: which unknown, if the answer came back badly, would end the company soonest? Answer that honestly and the choice makes itself.
If your biggest risk is technical
You need a PoC. The tell is that you cannot get a straight answer from engineers about whether something is possible, and the estimates you get vary by a factor of five.
That variance is not incompetence. It is the honest signal that nobody knows yet, and a PoC is how you buy the answer instead of guessing at it.
If your biggest risk is whether anyone wants it
You need a prototype. The tell is that everybody agrees it could be built and nobody agrees on what it should do.
Prototypes are also the right answer when the founding team disagrees about the product. Five user sessions settle an argument that six months of meetings will not.
If your biggest risk is fundraising
Be honest about this one, because it changes the answer.
If you need something to show investors, a high fidelity prototype is usually the better buy. It demos well, it costs less, and it can be produced in a week. A PoC in the same situation shows a room full of people a terminal window.
That is a legitimate reason to choose a prototype. Just do not tell yourself you have de-risked the build, because you have not.
If you genuinely have both risks
Run the PoC first, then the prototype. Two reasons.
Feasibility gates everything. There is no point designing an experience around a capability that turns out to be impossible, and a failed PoC saves you the entire design cost.
The PoC also tells the designer what the constraints are. If the model takes nine seconds to respond, that fact should shape the interface, and it is much cheaper to know that before the screens exist than after.
If you cannot name your riskiest question
Then you are not ready to buy any of the three, and the honest next step is discovery rather than a build. We covered how that differs from jumping straight in at product discovery vs MVP, and idea validation is the version of it we run.
Three real situations, and what each one needed
The abstract version of this decision is easy to agree with and hard to apply. Here is what it looks like against actual products.
A logistics platform that needed a PoC
The pitch was automatic reconciliation between a carrier’s tracking feed and a client’s warehouse system. Everyone agreed the interface was obvious. Nobody could say whether the two systems could be matched at all, because neither had a stable identifier for the same shipment.
That is a pure feasibility question, and it was answered in three weeks against a real data extract. The verdict was a qualified yes at 94 percent match, with the remaining 6 percent needing a human. That number changed the product, because it meant the design had to include an exceptions queue nobody had drawn.
A prototype here would have produced beautiful screens for a workflow that did not yet exist.
A marketplace that needed a prototype
Two founders, one convinced the product was a booking tool, the other convinced it was a discovery tool. Both were right about the technology, which was ordinary, and the engineering estimate never varied.
Five sessions with a clickable prototype settled it in a week. Four of the five participants went straight to search and ignored the calendar entirely. The argument that six months of meetings had not resolved was over by Thursday.
A PoC here would have proved that a booking system can be built, which nobody doubted.
A fintech tool that needed both
An unproven model for categorising transactions, plus a genuinely novel interface for correcting it. Two real risks, one technical and one human.
PoC first, four weeks, because the model’s response time was unknown. It came back at nine seconds per batch, which is fine for an overnight job and unusable for a live screen. The prototype that followed was designed around an overnight job.
Had those run in the other order, the design would have been thrown away.
How each one is scoped and contracted
Scoping a PoC
One question, written down, with the acceptance criteria attached. “Accuracy above 92 percent on a sample of 500 real invoices” is a scope. “Explore whether AI can help with invoices” is a budget with no end.
Fix the duration and the price. A PoC on hourly billing has no reason to conclude, and the incentive structure is exactly backwards.
Scoping a prototype
Name the fidelity, the number of screens, and the number of user sessions included. The sessions matter more than the screens, because a prototype nobody tests is just an expensive picture.
Five participants surface most usability problems. Booking them is usually the slowest part, so start recruiting before the design is finished.
Red flags in either proposal
- A PoC quoted at eight weeks or more without a scope split.
- A prototype quote with no user testing included.
- Either one described as “the first phase of the MVP” without a separate decision point at the end.
- No named engineer or designer, only roles.
- A vendor who will not tell you what a no looks like.
What happens to the work afterwards
PoC code should not become your product. It was written to answer a question, not to be maintained, and promoting it means inheriting every shortcut that made it fast.
Prototype design usually does carry forward, which is the one place where the cheaper artefact leaves more behind. Ask for the source files, not just the share link, and confirm you own them.
The mistakes that cost the most
Calling an MVP a prototype to make it sound cheaper. The word does not change the scope. You will get an invoice for a build.
Running a PoC with two questions in it. It doubles the timeline and produces an answer to neither, because the two unknowns interact and nobody can tell which one caused the result.
Testing a prototype only with people who love you. Friends, advisors and investors are not users. They are being kind, and kindness is not data.
Treating a successful PoC as permission to skip validation. You proved it can be built. You have learned nothing about whether it should be.
Promoting PoC code to production. The most expensive of the five, and the one that arrives eighteen months later disguised as unexplained slowness.
Skipping straight to the MVP because both feel like a delay. Sometimes correct, often the reason a $60,000 build gets thrown away. If you can name your riskiest assumption, spend three weeks testing it first.
Conclusion
A proof of concept and a prototype are not two sizes of the same thing. One is code with no interface that tells you whether the machine can work. The other is an interface with no code that tells you whether the person wants it.
Pick based on which unknown would end the company soonest, not on which one demos better and not on which one is cheaper. If both risks are real, run the PoC first so the constraints it uncovers can shape the design that follows.
And if what you actually need is the real thing, skip both. The artefacts are there to buy you certainty, and buying certainty you already have is the most expensive thing on this page.
We build proofs of concept on fixed scope with a written verdict at the end, including when the verdict is that you should not build it. If you would rather work out which of the three you need first, that conversation is here.
Frequently Asked Questions
What is the difference between a PoC and a prototype?
A proof of concept is working code with no interface that answers whether something can be built. A prototype is an interface with no working code that answers whether anyone would use it. A PoC removes technical risk and is judged by engineers. A prototype removes market and usability risk and is judged by users.
What is the difference between a PoC, a prototype and an MVP?
A PoC has working code but no real interface and no real users. A prototype has a real interface but no working code and no real users. An MVP has all three: working code, a real interface, and real users on real data. Each of the first two is missing a different piece on purpose so it can answer one question cheaply.
Which comes first, a PoC or a prototype?
Whichever answers the question that would kill the product soonest. If the technical unknown is the bigger risk, run the PoC first, because there is no point designing an experience around a capability that turns out to be impossible. If everyone agrees it can be built and nobody agrees what it should do, start with the prototype.
How long does a PoC take compared to a prototype?
A PoC typically runs two to four weeks. A prototype typically runs one to three weeks, depending on fidelity and screen count. Anything quoted at eight weeks or more is not a PoC, it is a small build with more than one question inside it.
How much does a proof of concept cost versus a prototype?
A PoC typically costs $8,000 to $30,000, driven by the difficulty of the technical question rather than the size of the product. A prototype typically costs $4,000 to $20,000, driven by fidelity and the number of screens. Neither price should be open ended, because both have a defined question to answer.
Can a prototype become the real product?
The design usually carries forward. The prototype itself does not, because there is no working code inside it to keep. Ask for the source design files rather than a share link, and confirm ownership in the contract so the build team can work from them directly.
Can a PoC become the real product?
It should not. PoC code is written for speed, which means no error handling, no tests, credentials in config and no thought about scale. If it does get promoted, budget the rewrite honestly at the time rather than discovering it eighteen months later as unexplained slowness.
Do I need both a PoC and a prototype?
Most founders need one, not both. You need both when you genuinely have two open risks: an unproven technical capability and an unproven user need. In that case run the PoC first, because its findings constrain the design and a failed PoC saves you the entire design cost.
What does a successful PoC look like if the answer is no?
It looks like a two page memo saying what was tested, on what data, what the result was, and what the team is now confident about. A clear no in week three for $14,000 instead of month five for $90,000 is the PoC working exactly as intended. A vendor who cannot deliver a no is running a sales process.
Which one is better for showing investors?
A high fidelity prototype, almost always. It demos well, costs less, and can be produced in a week, whereas a PoC shows a room a terminal window. That is a legitimate reason to choose one. Just do not confuse a good demo with having de-risked the build, because a prototype gives you no signal at all about whether the thing can be made.
