Short answer: build a prototype when the open question is about user experience, a POC when it's about whether something can work technically or commercially, and an MVP when you're confident enough to put a real product in front of real users. Most products with technical risk benefit from a POC first.
Why the distinction matters
Teams lose money in two predictable ways. Some build a polished MVP on top of an assumption nobody tested — an integration that turns out to be unreliable, a TV platform that can't play the required video format, a workflow users don't actually follow. Others build a quick demo to win approval, then discover it can't be extended and the "real" build starts from zero.
Both mistakes come from being vague about what the first build is for. Naming it correctly forces that conversation.
Definitions that hold up in practice
Proof of concept (POC)
A POC is working software built to answer specific questions about feasibility. Can we stream protected video to this device? Will the ERP's API return data fast enough for a customer portal? Can one content API serve web, mobile and TV apps? A POC implements just enough real functionality to answer those questions with evidence.
Prototype
A prototype shows how a product might look and feel. It ranges from paper sketches to clickable designs in Figma to coded front-ends with fake data. Its job is to test understanding and usability, and to align stakeholders on the experience. It usually proves nothing about the backend.
Minimum viable product (MVP)
An MVP is the smallest version of the product that real users can rely on, released to learn from actual usage. It needs to be production-grade where it matters: security, data integrity, reliability and support.
Side-by-side comparison
| Aspect | POC | Prototype | MVP |
|---|---|---|---|
| Main question | Can it work? | Does it make sense to users? | Will people use and pay for it? |
| Working software | Yes, for core flows | Rarely | Yes |
| Audience | Team, stakeholders, selected users | Stakeholders, test users | Real users or customers |
| Production-ready | Not necessarily | No | Yes, within scope |
| Architecture | Designed for validation and future direction | Lightweight or none | Production-oriented |
Terminology varies between companies, and that's fine. What matters is that everyone agrees what the first build must prove and what it's allowed to skip.
How to choose what to build first
List your biggest assumptions and ask which kind of risk each represents:
- Technical risk — "the integration will work", "the TV app will perform on older models", "the AI feature will be accurate enough". These call for a POC.
- Experience risk — "users will understand the onboarding", "editors will prefer the new workflow". These call for a prototype, or a POC with a usable interface.
- Market risk — "people will pay for this", "usage will be weekly, not monthly". These need an MVP with real users.
Then tackle them in order of cost-if-wrong. Technical risks are usually the most expensive to discover late, which is why a POC often comes first for complex products — particularly multi-platform, integration-heavy or video products.
The throwaway-POC trap
A POC doesn't have to be throwaway. The common pattern of "hack it together, then rewrite" made sense when the POC was a one-week spike. For a POC that proves a multi-platform product, rewriting means paying twice and re-learning lessons.
The alternative is to scope the POC narrowly but build it on the intended architecture: the real API boundaries, the real data model for the parts in scope, the real authentication approach. Shortcuts are still allowed — they're just deliberate and written down, so the production roadmap can address them.
The goal isn't to build a disposable demo. The goal is to create a useful first foundation.
A worked example
Imagine a media company planning a subscription video service on web, iOS, Android, Roku and Samsung TVs. The prototype question ("is the browse experience clear?") is real but low-risk. The expensive unknowns are technical: can one catalogue API serve all five clients efficiently, will DRM-protected playback work on the target TV models, and does TV sign-in via activation code work with the chosen identity provider?
A sensible first build is a POC: CMS to API to a web player and one TV platform, with entitlements and protected playback. If it proves out, the MVP adds the remaining platforms on the same foundation. See how we approach OTT development.
Summary
- Prototype → test the experience. POC → test feasibility. MVP → test the market.
- Pick based on your riskiest, most expensive assumption.
- Build POCs on the intended architecture so validated work carries forward.