Somewhere in every planning meeting, someone says "let's just build a quick proof of concept," and three people hear three different things. One hears a throwaway script. One hears a clickable demo for the investor call. One hears "the first version of the product."
Those are three different experiments. They answer different questions, they're built for different people, and the code from each should be treated differently. Mixing them up is how teams end up demoing a mockup as if it were a product, or shipping a spike to paying users.
A quick note on terms: PoC is short for proof of concept, and MVP is short for minimum viable product. I'll use the short forms after this.
I work at Entalogics, where we build proofs of concept and prototypes for startups, so I have a stake in getting this right. Here's the version I'd give a new engineer on day one.
The short version
Proof of concept (PoC)
- Question: Can we build it?
- Audience: You and your engineers
- Success looks like: The risky technical thing works
- The code: Throw it away
Prototype
- Question: Will people understand and use it?
- Audience: Users, stakeholders, investors
- Success looks like: Users get through the flow without help
- The code: Treat it as disposable
Minimum viable product (MVP)
- Question: Will people want it and pay for it?
- Audience: Real customers
- Success looks like: People sign up, stay or pay
- The code: Build it properly
The rest of this post is the reasoning behind that summary.
Proof of concept: can we build it?
A proof of concept exists to kill technical risk. Is the model accurate enough on your data? Can the third-party API handle your load? Does the integration actually work with the customer's system?
AWS Prescriptive Guidance puts it well: the PoC "must prove that the solution is technically buildable within the organization's specific environment." It also names the most common way PoCs go wrong: "Too often, PoCs are treated as technical demos that are designed to impress rather than as rigorous experiments that are designed to promote learning." Their other test is worth stealing: a PoC must first answer, "If we build this, will it matter?"
A good PoC can be ugly, and often is. What matters is that a number and a threshold are written down before the experiment starts. If you can't say what result would make you stop, you're building a demo, not running a proof of concept.
When to skip it: if the technology is boring (a CRUD web app on a stack your team knows), there's no technical risk to remove. Start at the next step.
Prototype: will people get it?
A prototype is about the human side. Does the flow make sense? Do users find the button? Can an investor click through the idea in two minutes and understand what you're building?
Nielsen Norman Group's definition is the one I like: "A user interface prototype is a hypothesis — a candidate design solution that you consider for a specific design problem." You test it by watching people use it.
They also explain why prototypes are cheap to learn from: "Ripping up code is very expensive. Ripping up a prototype is not." And they flag the trap that causes so much trouble in practice: "High-fidelity prototypes often look like 'live' software to users."
That last line is the whole problem. A polished clickable demo looks like a product. Stakeholders start asking when it launches. Someone suggests "just connecting the backend." The prototype did its job, which was to be convincing, and now it's being asked to be real.
Wireframe vs mockup vs prototype
These three get confused with each other all the time, so here's the quick split:
- Wireframe: a bare, low-detail sketch of a screen's layout. Boxes, labels, no colors, no real content. It answers "what goes where?"
- Mockup: a static, polished picture of how a screen will look, with real colors, fonts and images. You can look at it, but you can't click anything.
- Prototype: something you can use. You click through screens and the flow responds, even if nothing real is happening behind it.
A mockup shows what the product looks like. A prototype shows how it behaves. That difference is why a prototype can test whether people understand your idea and a mockup can't.
MVP: will they want it and pay?
A minimum viable product is the first version you put in front of real customers to learn whether they'll use it. Eric Ries's definition is the standard one: "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." He adds that "MVP, despite the name, is not about creating minimal products."
Two things matter in that definition. The point is learning, not shipping fast. And the learning is about customers, not about whether your code compiles.
The risk it addresses is a big one. CB Insights' March 2026 analysis looked at 431 VC-backed companies that shut down since 2023. For the 385 where a reason could be identified, poor product-market fit showed up in 43%. "Ran out of capital" showed up in 70%, but CB Insights calls that "almost always the final cause of death, not the root problem." (A company can have more than one reason, which is why the numbers add up to more than 100%.)
Notice that a minimum viable product is the first of these three that has to be real. Real users, real data, real consequences if it breaks.
One story with all three in it: Dropbox
The Dropbox launch video is usually told as "they validated with a video and no code." The details are more useful than that.
Drew Houston has said the team made two videos. The first went on Hacker News in 2007. The second, about a year later, went on Digg, and according to Houston the waiting list jumped from 5,000 people to 75,000 the day after. So the famous jump came after the second video.
And the video showed working software, not a pure mockup. The hard technical question, whether file sync could be made to feel seamless, had already been answered. That's the proof of concept. The video was a demo showing people what that would feel like, which is prototype territory. The waiting list measured whether people wanted it, which is the MVP question, tested before the full product existed.
One company, three different experiments, in the right order, each with one question.
The part developers should care about: don't promote the code
Here's my strongest opinion in this post. Nothing in a proof of concept or prototype repo should be promoted to production by default.
This isn't new. Fred Brooks wrote it in The Mythical Man-Month in 1975: "Hence plan to throw one away; you will, anyhow." What's changed is that AI tools have made the first version so fast and so convincing that the temptation to keep it is stronger than ever.
Thoughtworks' Technology Radar drew the line clearly in April 2025, when it put "complacency with AI-generated code" on Hold. Its wording: "While this approach can be appropriate for things like prototypes or other types of throw-away code, we strongly caution against using it for production code."
The data backs the caution. Veracode's 2025 GenAI Code Security Report found that AI-generated code introduced risky security flaws in 45% of tests, across more than 100 language models. (Veracode sells application security testing, so weigh that.) We covered what those flaws tend to look like in our breakdown of the hidden security risks in vibe-coded apps: packages that don't exist, secrets hardcoded into the source, and databases left open.
None of that is a problem in a prototype with fake data and no real users. It becomes a problem the moment the prototype is quietly promoted.
A few habits that keep prototypes honest:
Put prototypes and PoCs in their own repo, not a branch of the product repo.
Use sample data and demo credentials only. Never a production secret, never real customer data.
Write it in the README on line one: "Prototype. Not production code."
Decide up front, per component, what you'll keep. Keep the learnings and the design decisions. Rebuild the code on purpose.
Where a 72-hour build fits
Yes, our service page says proof of concept development. By the definitions above, what it delivers is a prototype: a fixed-price, clickable build for founders who need to show investors something real, from $999, up to 5 screens, with a scope call, a build, a polish and deploy step, and a handoff. The 72 hours is our own offer, not an industry norm, and nobody has published a trustworthy benchmark for how long these should take.
It answers "will people get this?" and "can we show it?" It does not answer "can it be built at scale?" or "will they pay?", and it isn't an MVP or production code. That's exactly why I'd call it a prototype: it's built to be demoed, not shipped. If you get one from us or from anyone else, treat the code as disposable.
How to choose
Pick by the biggest risk you're carrying, not by the label.
- Risk is technical (new tech, messy data, an integration nobody has tried): run a proof of concept first, with a pass/fail threshold written down.
- Risk is comprehension or buy-in (will users or investors understand this?): build a prototype and watch people use it.
- Risk is demand (will anyone pay?): build a minimum viable product, or test demand cheaply before you build anything.
You often need more than one, in that order. You often don't need all three. A boring-tech product with a clear user doesn't need a proof of concept. A product with proven demand doesn't need another prototype.
And don't ask one experiment to answer another one's question. People clicking through a demo and saying "this is cool" tells you the prototype works. It tells you nothing about whether they'll pay.
The takeaway
AI has made prototypes cheap, and that's good news. The failure mode has shifted from "we couldn't build a demo" to "we mistook a fast demo for a finished product."
Name the experiment you're running, write down what result would change your mind, and plan from the start for the code to be thrown away. When you do build the real thing, build it on purpose.
Top comments (0)