TL;DR: A proof of concept, a prototype and an MVP answer three different questions. A proof of concept asks "can this be built at all?" and tests the one technical risk nobody is sure about. A prototype asks "is this the right thing?" and puts something clickable or callable in front of people so they can react to it. An MVP asks "will people actually use it, or pay for it?" and is a real product with real users. Most founders ask for the wrong one first. If the hard part is technical, start with a proof of concept. If the hard part is knowing what users want, start with a prototype. If you already know both, go straight to an MVP. I have built all three, in AR and XR at ARCortex and Nystag, in AI voice agents at Fortell AI and Tested Media, and in my own products like LectureNotes AI, and the cheapest projects were always the ones where we picked the right question before writing code.
A founder once asked me for "a quick MVP" when what they actually needed was an answer to a single technical question that would have taken a week to test. Another asked for "a proof of concept" and meant a polished demo for investors. The words were doing a bad job of describing what they wanted, and the quote you get back depends heavily on which word you use.
This post is how I separate the three, when each one is worth paying for, and how to avoid building the expensive one when the cheap one would have told you what you needed.
The one question each one answers
The easiest way to tell them apart is to ask what you will know at the end that you do not know now.
- Proof of concept (PoC): you will know whether the risky technical part works. Nothing else.
- Prototype: you will know whether people understand it and want it, based on their reaction to something that looks or sounds real.
- MVP: you will know whether people use it repeatedly and, if money is part of the test, whether they pay.
If you cannot say which of those three things you are trying to learn, the project is not ready to be quoted yet. That is also the first thing I try to pin down in a project brief.
Proof of concept: testing the scary part
A proof of concept is small, ugly and focused on one risk. It often has no real interface at all. Its only job is to remove the "we are not sure this is even possible" from the project before anyone spends serious money.
Where I have seen a PoC earn its keep
In location-based AR, the scary part is almost never the 3D model. It is whether the virtual thing lines up with the real world well enough to be useful. At ARCortex, working on AR maps and tools for defense and enterprise projects, that alignment problem is the whole game, and I wrote about it in detail in the geospatial AR coordinate problem. You want to know early, with a rough test on real hardware outdoors, whether the overlay holds. A beautiful UI on top of an overlay that drifts is worthless.
Clinical XR has the same shape. On the eye-tracking diagnostics work at Nystag Healthcare XR, built on the Vive Focus 3, the question that matters most is technical: is the data coming off the headset good enough for the clinical purpose? That kind of question deserves its own focused test before you design screens for doctors. I covered more of that project in clinical XR eye-tracking diagnostics.
What a good PoC looks like
- It tests one risk, written down as a yes or no question before work starts.
- It runs on the real hardware, real data or real platform, not a simulator that hides the problem.
- It has a pass bar agreed in advance ("the overlay stays within X of the target while walking").
- It is allowed to be thrown away. Most of the code should not survive into the product.
When you do not need one
If the technology is well understood, a PoC is wasted money. A voice agent that answers questions and books appointments on Retell is not a technical unknown anymore. Nobody needs to prove that it can be built. The open questions there are about the conversation and the business, which is prototype territory.
Prototype: testing the idea on people
A prototype is something people can react to. For an app, that can be clickable screens with fake data. For an AI voice agent, it is an agent that answers a real phone number and handles the main call path, even if nothing behind it is connected yet.
Voice agents are a good example
At Fortell AI I built a pipeline to build and test voice agents in minutes using Claude Code and Comet browser automation, which I described in building and testing voice agents with Claude Code and Comet. One side effect of being able to stand up an agent that fast is that the prototype stage becomes almost free. Instead of debating a call flow in a document, you put the client on the phone with a first version and let them hear it.
That changes the conversation completely. A clinic manager who says "it should sound friendlier" or "nobody calls us asking that, they ask this" in the first ten minutes of a test call has just saved weeks of building the wrong thing. The booking integration, the CRM writes and the follow-up texts can all wait until the conversation itself is right.
What a good prototype looks like
- It looks or sounds real enough that people react honestly, not politely.
- It covers the main path only. Edge cases come later.
- The backend is faked wherever possible: hardcoded data, a spreadsheet, a stub that returns a sensible answer.
- It is shown to real people from the target group, not just the founder's friends.
The trap
The biggest risk with a prototype is that it works too well in the demo. Everyone sees something that looks finished and assumes it is 80 percent done. It is not. A prototype with fake data and no error handling is maybe 20 percent of a product, and the remaining work is the part nobody sees: auth, real integrations, failures, logging and the edge cases. I am always explicit about this with clients so nobody is surprised when the MVP quote arrives.
MVP: testing behaviour, not opinions
An MVP is a real product. Real accounts, real data, real users who did not have to be asked twice. The difference from a prototype is that you stop measuring what people say and start measuring what they do.
With LectureNotes AI, the loop was simple: record a lecture, get a summary, takeaways and a clean outline. Opinions would never have told us what actually happened, which was around 15 million organic Instagram views in two months, close to 10k users and about $1k in monthly revenue. Those three numbers tell very different stories, and you only get them from a product that is genuinely live. The full breakdown is in the LectureNotes AI growth retrospective.
An MVP is also where foundations stop being optional. Ownership of accounts, basic analytics on the core loop, a version header if there is a mobile app, and a payment step if money is the question. I went through what to keep and what to cut in what to cut from an MVP.
Which one should you build first?
Here is the decision I walk through with founders.
- Is there a part of this nobody is sure can be built? New hardware, unusual data, a model doing something unproven, real-time positioning, a strict latency target. If yes, start with a proof of concept for that part only.
- Is the main uncertainty what users want or how they will react? If yes, build a prototype and put it in front of real people within days, not months.
- Are both of those already answered? Then go straight to an MVP and spend the money on the real thing.
Plenty of projects need two of the three. An AR product might need a PoC for alignment and then an MVP, skipping a separate prototype because the PoC already showed people the experience. A voice agent project usually skips the PoC entirely and goes prototype, then MVP. Very few projects need all three as separate builds.
How the three differ on cost and code
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question | Can it be built? | Is it the right thing? | Will people use or pay? |
| Audience | The team | Target users, the client | Real users |
| Typical length | Days to a couple of weeks | Days to a few weeks | Weeks to a few months |
| Code reused later | Little | Some, often the UI or prompts | Most of it |
| Polish | None | Enough to feel real | Good at the core loop |
Those timeframes are ranges from my own projects, not promises. AI voice agents sit at the fast end, and I broke down where the time actually goes in how long it takes to build an AI voice agent. Hardware-heavy AR and XR work sits at the slow end, mostly because testing has to happen in the field, not at a desk.
The table also matters for pricing. A PoC or prototype with a narrow question is easy to fix-price. An MVP with a long feature list is not, which I covered in fixed price vs hourly vs retainer.
The mistake I see most: shipping the prototype
The most expensive version of this is when a prototype quietly becomes the product. It got a good reaction, the founder is excited, and instead of rebuilding the parts that were faked, the team keeps adding features on top of hardcoded data and skipped error handling.
That works for a while. Then real users arrive, and the shortcuts become outages, data problems and a codebase that nobody wants to touch. A lot of the codebases I am asked to audit after inheriting them started life as a demo that was never meant to be shipped.
The fix is not to make prototypes slower. It is to decide, out loud and at the start, which parts are disposable. Keep the prompts, the copy, the flow and maybe the UI. Rebuild the data layer, the integrations and anything that touches money or personal information properly for the MVP.
I build proofs of concept, prototypes and production products across AI voice agents, web and mobile apps, and AR/XR, for founders in the US, UK and Europe. If you are not sure which one your idea needs first, more about my background here, or book a call and we can work out the right first question together.