In practice, a proof of concept (PoC) tells you whether an idea can be built: it proves that a technology works. An MVP tells you whether it should be built: it is a first version of the product, put in the hands of real people to see whether they use it. To validate an idea on the market you need the MVP; the PoC, when the doubt is technical.
The two questions are how we use these words at dotenv, and they rest on two public references: the technology maturity scale used by NASA and the European Commission, where the proof of concept has a precise place, and the definition of MVP given by Eric Ries in 2009.
What is a proof of concept?
It is an experimental proof that a technology can work. The most widely used reference is the Technology Readiness Levels (TRL) scale of NASA, nine levels from TRL 1 to TRL 9. At TRL 3 analytical and laboratory studies are needed to see whether a technology is viable, and NASA writes: “Often during TRL 3, a proof-of-concept model is constructed”.
The European Commission uses the same scale in the general annexes of the Horizon Europe Work Programme 2026-2027, adopted by decision C(2025) 8493 of 11 December 2025. There TRL 3 is called “Experimental proof of concept”. TRL 9 is “Actual system proven in an operational environment”.
In software the question a PoC asks is usually concrete: whether an algorithm holds up with real data, whether two systems can talk to each other, whether an integration with a system that already exists can be done, and with what limits.
Is a proof of concept a prototype?
On the NASA scale they are two different levels. The proof of concept sits at TRL 3, a fully functional prototype arrives at TRL 6, and a technology is called TRL 9 only after it has worked on a real mission. In the Horizon Europe annexes TRL 7 is “System prototype demonstration in an operational environment”.
With a supplier it pays to say which of the two you are asking for: the first tests a technology, the second shows a system that works.
What is an MVP?
It is the version of a new product that lets you learn as much as possible about customers with the least effort. The definition is Eric Ries’s, in the post “Minimum Viable Product: a guide” of 3 August 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 word that matters is validated learning: an MVP is judged by how much it teaches you about customers. In the same post Ries warns that the MVP, “despite the name, is not about creating minimal products”, and that the definition calls for judgement: which MVP makes sense depends on the context.
What is the difference between an MVP and a proof of concept?
They answer two different questions, and the Lean Startup method keeps them apart. The method’s website describes every startup as a large experiment that tries to answer a question, and the question “is not “Can this product be built?” Instead, the questions are “Should this product be built?” and “Can we build a sustainable business around this set of products and services?””. According to the same website, the first step is to understand the problem to be solved; then an MVP is developed “to begin the process of learning as quickly as possible”.
Reading “can it be built?” as the PoC’s question and “should it be built?” as the MVP’s is our own reading: the Lean Startup website talks about startups, the TRL scale about technologies. Side by side, the two line up like this:
| Proof of concept | MVP | |
|---|---|---|
| The question | Can it be built? | Should it be built? |
| What it proves | That a technology is viable | What you learn about customers |
| Where it sits | TRL 3 on the NASA and Horizon Europe scale | In the Lean Startup method, after understanding the problem to be solved |
To validate an idea, do you need a PoC or an MVP?
It depends on the doubt the idea carries with it: if it is technical, a PoC; if it is the market, an MVP. The data on startups that shut down say which of the two doubts weighs more.
CB Insights, in its report of 5 March 2026, analysed public post-mortems, founder interviews and closure announcements of 431 venture-backed startups that have shut down since 2023. The percentages below refer to the startups whose reasons are known, and they add up to more than 100 because many cite more than one.
At the top of the list is “ran out of capital”, at 70%, and the report regards it almost always as the final cause. The causes that explain why the capital ran out are:
- poor product-market fit, 43%;
- bad timing, 29%;
- unsustainable unit economics, 19%.
According to the same report, two thirds of product-market fit failures involve early-stage companies that never found a market, and the median time between the last funding round and closure is 22 months.
Poor product-market fit is a market risk, and a technical feasibility test does not measure it. The sample is of venture-backed startups and the source does not say which countries they are from: for an idea funded another way the numbers should be taken as an indication.
If the technology is new you do both, first the PoC and then the MVP. If it is well known, as for an app or a portal, you can start from the MVP.
Do you need an MVP if the product has already been decided?
Usually not: if the question “should it be built?” already has an answer, what you need is a team that builds what has been decided. The page of our product puts it like this: “Then it is custom software, on a normal quote.”
How long does an MVP take?
It depends on what it has to teach you. In the 2009 post Ries recounts that IMVU’s original MVP took six months to reach the market. In another case the team spent two weeks building a feature nobody wanted, and a simple smoke test with AdWords would have revealed it sooner.
The time can also be fixed before you start. From idea to business is dotenv’s product for taking an idea to a product that someone uses, in eight weeks from signature. The date does not move for a new request or for a delay, and the same people work on it from the first day to the last. Every Friday we decide together what goes in and what comes out: the content changes, and the deadline stays the same. At the end there is a dossier for deciding whether to fund the next phase. If you decide to stop, code, documentation, collected data and analysis remain yours.
Within dotenv we founded Neurally, an AI company. It is the only time the client was us, with the idea and the risk of finding out that it did not stand up.