PoC vs MVP: What Is the Difference? Purpose, Timeline and Process Compared

"We were told to start with a PoC, but how is it different from an MVP?" "Our PoC succeeded, but nothing happened after it." In consultations about new businesses and AI adoption, we often see misunderstandings that begin with these two terms being mixed up.

A proof of concept (PoC) checks whether something can be built with a given approach. A minimum viable product (MVP) checks whether what you built will actually be used. Because the questions differ, so do the timeline, the process and the way each one ends.

This article explains the purpose of each, how their timelines and processes differ, why projects get stuck at the PoC stage, how to choose which to start with, and how they relate to contract types, from our perspective as a company that supports both.

PoC stands for proof of concept and MVP for minimum viable product, but in practice both are explained as "build something small and check it", so the difference is hard to see. The surest way to tell them apart is by what each one checks.

What is a proof of concept (PoC)?

A PoC is a small build that checks whether a given approach or technology can achieve the goal. It answers technical questions: can AI read handwritten slips, can data be pulled out of the existing core business system, can the processing run at the speed required?

The users are in-house staff or a small group of collaborators, and you build only the part you want to test. Screens and operational processes are not built out. It ends with a record of "it worked" or "it did not", together with the conditions (accuracy, speed, cost).

As a guide, a PoC takes from a few weeks to two or three months. If the question is narrowed down to one, it is short; if not, it drags on.

What is a minimum viable product (MVP)?

An MVP is an approach in which you build a product with only the minimum features needed to test a business hypothesis, and judge by how real users respond. Eric Ries, who popularised the term, defined it in 2009: "the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort". The model contract published by IPA (Information-technology Promotion Agency, Japan) also describes MVP development as developing a minimum viable product.

The users are real users, and what you build is the smallest product that delivers value. Design and operations can be minimal, but the quality must be good enough for continued use. It ends with numbers on whether it was used, and a decision to continue, change or stop.

As a guide, an MVP takes from a few weeks to about three months if the scope is tight. The main cause of delay is not the amount of implementation but waiting for specifications to be decided. We cover the process in detail in What Is MVP Development?.

Purpose, timeline and process compared

A prototype, which checks the look and flow of screens, is different again: it is a non-working screen reviewed with in-house stakeholders.

How a PoC and an MVP proceed

A PoC follows four steps.

• Decide on one question. Make it a question with a clear answer, such as "can handwritten slips be read?".
• Write the success criteria first. Set figures for accuracy, speed and cost, and decide what you will judge once they are met.
• Test with data close to production. Use at least part of the real data and volume from the field, not clean samples.
• Record the results and conditions. Keep not only whether it worked but under which conditions, and hand that to the next decision.

An MVP starts by narrowing down to one hypothesis to test. Select only the features needed to test it, build them to a quality that can be used continuously, and have real users use them. Build measurement in from the start, and decide to continue, change or stop based on the numbers.

In both cases, what determines timeline and cost is not the amount you build but whether the question has been narrowed down to one. With several questions, there is more to build and more to check, and the timeline stretches.

Why projects get stuck at the PoC stage

When a PoC succeeds but never reaches production, known as getting stuck at the PoC stage, the causes are usually the same.

• Only a technical question was asked. Being able to read the slips and the field continuing to use the system are different questions. If the PoC plan does not say who decides what once it succeeds, nothing starts after success.
• The success criteria were set afterwards. What accuracy justifies going ahead, and what cost makes it viable, need to be decided before you start. Set afterwards, the criteria shift to fit the results.
• Production conditions were left out. The test ran on clean sample data and does not work on real data from the field. Use at least part of the production-like data and volume at the PoC stage.
• The field was not involved. A PoC run only by the IT department has no plan for entering the field's daily work, even if it succeeds. From the PoC stage, have staff in the department that will actually use it try it, and decide who will run it in production.
• PoCs are repeated. Each time one ends, the next technology is tried, and the business question is never reached. Once the technical uncertainty is low enough, move on to the business question with an MVP.

Which to start with

Choose by where the biggest uncertainty lies today.

• If the uncertainty is technical, start with a PoC. This is when you do not know whether an unprecedented level of AI accuracy, a connection to an external system or the required processing speed is achievable.
• If the uncertainty is in the business, start with an MVP. This is when you know it can be built, but not whether anyone will use it or keep using it.
• If both, finish a short PoC and then move to an MVP. Keep the PoC as short as possible and get to the business question early.
• If neither, you need neither. If what you are building is already decided, go straight to normal development.

For most business systems, it is already known that they can be built, so skipping the PoC and starting with an MVP gets you to an answer faster. In AI adoption, technical uncertainty often remains, so a short PoC is worth having.

How contract types fit

With both a PoC and an MVP, what you build next depends on the result. A quasi-mandate contract (jun-inin, a time-and-materials style contract), which pays for the work performed, therefore fits better than a fixed-price contract (ukeoi), which promises completion of a defined deliverable. IPA's model contract (agile development edition) also assumes a quasi-mandate contract.

The usual approach is to switch to a fixed-price contract for full development once the validation is over and the scope is settled. We explain the differences between contracts in What Is a Quasi-Mandate Contract? and What Is Fixed-Price (Ukeoi) Development?.

What AI has changed

AI-assisted development has shortened implementation time. A PoC now often produces results in days, and an MVP can be built with a smaller team than before.

As a result, the decision that carries more weight is narrowing down what to test. Precisely because things can be built, narrowing the question to one and setting the success criteria first now shape the outcome more than before. As a business co-creation partner, we work with you from the point of narrowing that question.

FAQ

Do we need both a PoC and an MVP?

No. If there is no technical uncertainty, you can skip the PoC, and if what you are building is already decided, you do not need an MVP either. Choose by where the biggest uncertainty lies today.

What is the difference between a PoC and a prototype?

A PoC checks whether something is technically feasible. A prototype is a mock-up for checking the look and flow of screens in-house, and it may not work at all.

How should we set the success criteria for a PoC?

Work back from the conditions under which it would be viable in production. Decide figures you can use to go ahead or stop: accuracy of at least a certain percentage, processing within a certain number of seconds per item, cost within a certain amount per month.

Can what we build as an MVP be used in production as is?

Sometimes yes, sometimes no. Because an MVP is for validation, it often has only minimal provision for growth in user numbers and for how critical uptime is. Once it passes validation, you decide which parts to rebuild.

Which contract type should we use for a PoC or an MVP?

Because what you build next depends on the result, a quasi-mandate contract fits better. The usual approach is to switch to a fixed-price contract for full development once the scope is settled.

Summary

A PoC is the technical gate: it checks in-house whether something can be built. An MVP is the business gate: it checks with real users whether it will be used. The questions differ, so the timeline, process and ending differ too.

Which to start with depends on where the biggest uncertainty lies today. Talk to your project manager through our free estimate consultation, starting with working out what you should test. We also describe how we run PoC and MVP development on PoC and MVP development.

Related articles and pages

• What Is MVP Development? Process, Cost and How It Differs from a PoC
• What Is a Quasi-Mandate Contract? When to Use It in System Development and How It Differs from Fixed-Price
• What Is Fixed-Price (Ukeoi) Development? Pros, Cons and How It Differs from Quasi-Mandate Contracts
• What Is Lab-Type Development? When a Dedicated Team Fits, and How It Differs from Fixed-Price and Quasi-Mandate
• What Is Contract Development? Contract Types and What to Decide Before You Order
• PoC and MVP development: from hypothesis testing to full development
• Free estimate consultation: discuss scope and a cost range with a project manager

Sources

• Eric Ries, "Minimum Viable Product: a guide", 3 August 2009
• IPA, "Model Transaction Contract for Information Systems (Agile Development Edition)", 31 March 2020 (in Japanese)
• e-Gov Law Search, "Civil Code (Act No. 89 of 1896)", Articles 632 and 656 (in Japanese)