PoC vs Prototype vs MVP: Which to Build First (and for AI)

PoC vs prototype vs MVP sounds like a vocabulary question, but the founder or CTO asking it usually has a money question underneath: what is the cheapest thing we can build next that tells us whether to keep going? Each of the three answers a different question — can it be built, how will people use it, will anyone use it for real — and building the wrong one first is how teams spend three months proving something nobody doubted.

This guide gives you sharp definitions, a side-by-side comparison, a decision tree for what to build now, rough effort shapes, and the part most guides skip: what changes when the product depends on AI, where an impressive demo proves very little.

The short version

• A proof of concept (PoC) answers "can this be built?" It is a technical experiment, usually thrown away, that ends in a go/no-go.
• A prototype answers "how will people use it?" It simulates the product so you can test the flow with users before paying to build it.
• An MVP (minimum viable product) answers "will people actually use it, or pay for it?" It is real software, used by real users, on code you keep.
• Build first whatever retires your biggest unknown: technical risk → PoC; usability risk → prototype; demand risk → MVP. For AI, a PoC only counts if it clears a pass bar agreed in advance, on an evaluation set of your real data, against a baseline.

What is the difference between a PoC, a prototype and an MVP?

A PoC tests feasibility, a prototype tests the experience, and an MVP tests demand. They are not three rungs of one ladder that every product must climb. They are three different experiments, each designed to kill a different kind of risk as cheaply as possible — and many good products skip one or two of them.

Two rows matter more than the rest. First, only the MVP is built to be kept — the PoC and the prototype are disposable by design, and most expensive mistakes come from forgetting that. Second, each one has an exit criterion. If you can't say, before you start, what result would make you stop, you're not running an experiment; you're building on hope.

What is a proof of concept (PoC) in software development?

A proof of concept in software development is a small, deliberately incomplete build that answers one technical question: can this core mechanism work under the constraints that matter? It is not a product and not meant for users. A good PoC isolates the riskiest technical assumption — an integration nobody has done, a performance target, an algorithm on real data — tests only that, and ends with a pass or a fail against a criterion agreed before anyone wrote code.

Typical PoC questions look like this:

• "Can we read and write orders through the legacy ERP without a nightly batch export?"
• "Can we match our product catalogue against a supplier's feed fast enough to run on every price update?"
• "Can a model pull the fields we need from scanned invoices accurately enough to skip manual entry?"

What a PoC deliberately leaves out: the interface, user accounts, error handling, scaling, and any test that isn't needed to trust the result. It is cheap because it is incomplete. And if there is no technical unknown — a portal or internal tool on a standard stack with documented integrations — there is nothing for a PoC to prove.

The pitfall — the PoC that never dies. It worked, someone demoed it, and three months later it's running in production with no tests, credentials in the code and a prompt nobody versioned. Decide upfront that PoC code is disposable, and treat "it worked" as permission to build it properly — not as the build.

What is a prototype in product development?

A prototype is a simulation of the product, built to test how people will use it — the flow, the layout, the wording — before you pay to build the real thing. The Nielsen Norman Group puts it precisely: "A user interface prototype is a hypothesis — a candidate design solution that you consider for a specific design problem" (NN/g, 2016). A prototype tests desirability and usability, not feasibility: the "smart recommendation" on screen can be hard-coded behind it, and that's fine.

Prototypes vary by fidelity — in NN/g's definition, "how closely it matches the look-and-feel of the final system":

• Low fidelity: sketches, paper, wireframes; links don't work and a person plays "the computer". Cheap and fast — right for testing whether the flow makes sense at all.
• High fidelity: clickable, close to the final visual design, with realistic content. Right for testing details, showing investors, and handing engineering a clear specification.

Textbooks list several prototype types (throwaway, evolutionary, incremental and more). For a founder they collapse into one decision: is this prototype disposable, or will it become the product? A throwaway prototype is honest about being fake and costs little. A prototype meant to grow into the product has to be written like production code from day one — at which point it's an early MVP and should be scoped and budgeted like one.

The pitfall — mistaking a convincing prototype for progress. A polished Figma flow, or a front-end generated in an afternoon with an AI coding tool, can look finished while the hard part — data, integrations, permissions, edge cases — hasn't started.

What is an MVP (minimum viable product)?

An MVP is the smallest version of the real product that real users can use to do a real job, released to learn whether they keep using it and pay for it. Eric Ries, who popularised the term, defined it as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Ries, 2009). The key word is validated: not opinions in a demo, but behaviour — sign-ups that activate, users who come back, customers who pay.

The two adjectives pull in opposite directions, and most MVP failures come from ignoring one of them:

• Minimum means narrow scope: one user type, one core job, the smallest feature set that delivers it. Not "everything, but rough".
• Viable means it genuinely works for that job: real authentication, real data, error handling, a deployment pipeline, and security proportionate to the data it holds. A product that falls over with its first real user teaches you nothing about demand — only that it falls over.

Demand is the risk worth paying to test. In CB Insights' 2026 analysis of 431 VC-backed startups that shut down since 2023, poor product-market fit was a cause in 43% of cases, while running out of capital (70%) was "almost always the final cause of death, not the root problem" (CB Insights, March 2026). An MVP is the cheapest way to find out whether you have product-market fit before the money runs out.

The pitfall — the MVP that is really a prototype. It ships without the parts that make it viable, the first customers hit bugs, data loss or downtime, and the learning is polluted: when users churn, you can't tell whether they didn't want the product or couldn't rely on it.

PoC vs prototype vs MVP: which one do you need right now?

Build first whatever retires your biggest unknown — not the one that feels most productive, and not the one your agency happens to sell. Walk through these questions in order and stop at the first "yes":

1. Is there a technical question nobody can answer with confidence? An untested integration, a performance or accuracy target, an AI capability on your own data. → Start with a PoC, scoped to that one question.
2. Is the technology standard, but you're unsure users will understand or want the flow? → Build a prototype and put it in front of a handful of target users.
3. Is the technology proven, the flow validated (or simple), and the open question whether people will use it and pay? → Build the MVP.
4. Do you already have paying users and a working product? → None of the three. Your open question is scale and reliability, which is roadmap and production engineering.

When a product carries both technical and market risk, the full sequence is PoC → prototype → MVP. But the sequence is a menu, not a mandate.

PoC vs prototype: which comes first?

When you need both, the PoC usually comes first — there's little point refining the flow of something that can't be built. The exception is when usability is the existential risk and the technical risk is cheap to test later; consumer onboarding is the classic case. With an engineer on the PoC and a designer on the prototype, run them in parallel.

Proof of concept vs MVP: can you skip straight to an MVP?

Yes, if nothing about the core technology is unproven. Most business software — portals, internal tools, dashboards on standard stacks — has no real feasibility question; a PoC there is paid procrastination, and the money is better spent on a narrower MVP. Don't skip it when the product's whole value rests on one technical bet.

Prototype vs MVP: what's the real difference?

A prototype simulates the product; an MVP is the product in its smallest real form. A prototype shows whether people understand and like the flow — stated preference, fast and cheap. An MVP shows whether they use it when it costs them time, data or money — behaviour, slower and costlier, and the only thing a funding or roadmap decision should rest on.

What about a pilot, or a proof of value (PoV)?

Two more terms show up in the same conversations, especially in B2B and enterprise buying:

• A pilot is the real solution deployed to a limited group — one team, one site, one region — in real operations, for a fixed period, to measure results before a full rollout. The difference between a prototype and a pilot: a prototype simulates the product for testing; a pilot runs the real product in the real environment at limited scale. A PoC asks "can it work?"; a pilot asks "does it work here, with our people and processes?"
• A proof of value (PoV) asks whether the solution delivers measurable business value — hours saved, errors avoided, revenue — usually on the customer's own data and against metrics both sides agreed. A PoC proves feasibility; a PoV proves it's worth paying for.

One rule covers both: a pilot with no end date and no success metric isn't a pilot — it's an unbudgeted production system. That is where most AI initiatives stall, which is the next section.

What is an AI proof of concept, and why is it different?

An AI proof of concept tests whether a model can meet a pass bar agreed in advance on your real data — not whether it can produce one impressive answer. That distinction is the whole game. With conventional software, a PoC that works once will mostly work again, because the code is deterministic. A language model can answer the same question well on Monday and badly on Tuesday, and a demo built on hand-picked inputs says almost nothing about the inputs production will send.

The cost of skipping this is documented. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, "due to poor data quality, inadequate risk controls, escalating costs or unclear business value" (Gartner, July 2024). Every one of those four causes can be measured in a well-designed AI PoC instead of being discovered after it.

The three things an AI PoC needs before anyone builds

1. An evaluation dataset from your real data. Real inputs — emails, documents, tickets, records — each paired with the correct output, written down by someone who knows the job. Include the ugly cases: the sideways scan, the ambiguous request, the input the system should refuse. For most business workflows that's dozens to a few hundred examples, not thousands, as long as they cover what production will send. Keep part of it held out — never used while tuning prompts — so the final score is honest.
2. A baseline. What happens today — the person doing it by hand, a simple rule, a keyword search — measured on the same dataset. Google's Rules of Machine Learning open with "Don't be afraid to launch a product without machine learning", and note that "a simple heuristic can get your product out the door" (Google for Developers). If a rule gets you most of the way, the model has to beat it by enough to pay for itself.
3. A success criterion with a number in it. Not "it should classify well", but a threshold on a metric, on the held-out set. Anthropic's evaluation guide describes good criteria as specific, measurable, achievable and relevant, and gives the shape: an F1 score of at least 0.85 on a held-out test set, "a 5% improvement over the current baseline" (Anthropic docs). Add a ceiling on cost per run and on response time, and a rule for when the system must say "I don't know" and hand the case to a person.

With those three in place, an AI PoC is an honest experiment: run it, score it, compare it to the baseline, decide. Without them it's a demo — and demos are designed to succeed.

Here is what a one-page AI PoC brief looks like. The numbers are illustrative; set your own.

Why AI demos mislead

• Selected inputs. The demo runs on cases chosen by the person who built it. Production sends everything else.
• One run is not a measurement. Model outputs vary between runs; a single success says little about the success rate.
• No cost at volume. A demo makes a handful of calls; production makes thousands, with longer inputs and retries.
• No refusal path. Demo agents always answer. Production agents need to know when not to.
• No integration. The demo reads pasted text; the real system has to read from and write to your CRM or ERP, with permissions and an audit trail.

We cover the full gap in why your AI agent isn't reliable enough to scale.

If the PoC uses personal data, GDPR applies to the experiment exactly as it applies to production. The European Commission's guidance on data minimisation is direct: "Where possible, it is preferable to use anonymous data", and where personal data is needed it should be "adequate, relevant, and limited to what is necessary for the purpose" (European Commission). In practice: anonymise or pseudonymise the evaluation set where you can, run the PoC in the environment you'd use in production, and never paste customer data into a consumer chatbot to "quickly test the idea". (General information, not legal advice — confirm your case with your data protection officer.)

From AI PoC to MVP to production

The evaluation set is the most valuable thing an AI PoC produces — more valuable than its code. It becomes the regression test that runs on every prompt or model change in the MVP and in production, so you know whether a change helped or hurt. The rest of that path is in how to deploy AI models to production and, for agents, how to build an AI agent.

Defining the criteria first is also what makes the later stages work. In the AI lead-qualification agent we built for OmniTrade Brasil — 1,200 CSV files a month, screening cut from days to hours — the scoring rules are explicit and configurable by the client. As the project lead put it: "The problem wasn't volume — it was structure. Once the business criteria had been clearly defined, the agent implemented them consistently."

How much do a PoC, a prototype and an MVP cost?

There is no honest single price, but there is an honest formula: cost ≈ people × weeks × blended rate — and the ratio between the three is more stable than any absolute number. Prices quoted online vary widely with country, seniority and scope, and most come without a source. What you can reason about is the shape of the effort.

The table below uses illustrative scoping assumptions — not market data and not a quote. Replace them with your own scope.

To turn effort into money, multiply the person-weeks by your blended weekly rate — the fully loaded cost of an in-house team, or a partner's rate. Our guide to software development cost estimation walks through the method, with a worked estimate you can copy.

Three things follow from the shape:

• A PoC or prototype costs a fraction of the MVP, so buying certainty on the riskiest assumption first is cheap insurance. Spending MVP money to discover a feasibility problem is the expensive way to learn it.
• MVP cost is driven by scope, not by the label. The fastest way to cut it is to drop a user type or a feature — not the "viable" parts like security, error handling and deployment, which you'd pay for twice later.
• AI adds a running cost. Model usage grows with volume and input length. Measure cost per run during the PoC, so the MVP business case includes it — escalating costs were one of the four causes in Gartner's abandoned-PoC prediction.

What are the most common mistakes with PoCs, prototypes and MVPs?

1. Shipping an MVP that is really a prototype — no authentication, no error handling, manual deploys — so you can't separate "didn't want it" from "couldn't trust it".
2. Letting the PoC become production because it worked once. Rebuild it properly; keep what it taught you, not its code.
3. Testing the wrong risk first: weeks of PoC on a standard integration while nobody has asked a customer whether they'd pay — or months of MVP on top of an AI capability nobody measured.
4. No exit criteria — the perpetual pilot. Without a pass bar and an end date, every result reads as "promising, let's extend it". Write the kill criterion down before you start.
5. Treating stated interest as demand. "I'd use that" in a prototype session is not a sign-up, and a sign-up is not a paying customer.
6. For AI: scoring the PoC on the examples used to build it. The prompt was tuned on those cases, so of course it passes. Only the held-out set predicts production.

What should a first version include, and how fast can it ship?

A first version should be a real MVP: narrow in scope, but production-grade in everything users touch — authentication, data handling, error handling, deployment and, for AI, an evaluation set and a human fallback. Speed comes from cutting scope, not corners.

This is how we run it at Unlocking Tech. The assessment comes before we touch code — and it can end in "don't build this". If there's a real technical unknown, usually an AI capability or a legacy integration, we scope a PoC around it with the pass bar agreed upfront. Then we build the MVP as production code from the first iteration, with weekly demos; our typical time to a first version in production is 9 weeks.

Where to go from here depends on what you're building:

• A product that needs to reach real users: our MVP development services.
• A product whose core is a model, an agent or a document pipeline: custom AI development.
• Not sure yet which of the three you need, or whether AI is the right tool at all: an AI readiness assessment is designed to answer exactly that.
• Deciding who should build it: in-house vs outsourced AI development and how to choose an AI development company.
• Deciding how to run the build once it starts: software development process models.

Frequently asked questions

Is a PoC the same as a prototype?

No. A PoC tests whether something can be built: it's technical, internal and usually has little or no interface. A prototype tests how the product will look and be used: it's about users and often has no real logic behind the screens. A PoC can be ugly and correct; a prototype can be beautiful and fake. Many products need one, some need both, and plenty need neither.

Can a prototype become the MVP?

Only if it was built to be kept. A clickable mockup or a front-end on hard-coded data can't — its job was to be thrown away. A coded prototype can evolve into the MVP if it was written with production practices from the start: version control, tests, real authentication and a deployment pipeline. Decide which kind you're building before you start, not after the demo goes well.

How long should a proof of concept take?

As long as it takes to answer its one question — usually days to a few weeks, not months. If a PoC keeps growing, either it has found that the answer is "no" and nobody wants to say so, or it has quietly turned into an MVP without the budget, scope and quality bar of one. Time-box it, and fix the pass and kill criteria before the first line of code.

What is an AI PoC?

An AI PoC (AI proof of concept) is a short experiment that tests whether an AI approach can solve one specific problem well enough on your own data. It needs three things defined upfront: an evaluation set of real examples with correct answers, a baseline for how the task performs today, and a numeric pass bar. The result is a go/no-go decision, not a demo.

What comes after an MVP?

Iteration on what the MVP taught you: invest in the features people actually use, cut what they ignore, and harden the product for scale — monitoring, performance, security and support. The decision point is evidence: activation, retention, revenue. If the MVP produced none of those, revisit the problem you're solving before adding features to the solution.

What is the difference between a PoC and a pilot?

A PoC tests feasibility in a controlled setting, usually run by the team that built it. A pilot runs the real solution in real operations with a limited group of users for a fixed period, to measure results before a full rollout. In short, a PoC asks "can it work?" and a pilot asks "does it work here, for us?" — so a PoC normally comes first.