These four words get used interchangeably in the same conversation, usually by people who mean four different things by them. The confusion is expensive because each answers a different question, and building the wrong one means spending real money to answer a question you did not have.
The clean way to separate them is by the question each is capable of settling.
Proof of concept: can this work at all
A proof of concept answers a technical feasibility question, and nothing else. Can this model reach acceptable accuracy on our documents. Can this data be extracted from that system at all. Can this run inside the latency budget.
It exists to remove a specific technical unknown, so it should be built to be thrown away. No interface beyond what is needed to see the result, no error handling, no permissions, no deployment. Anything spent making it presentable is spent on the wrong question.
A proof of concept is finished when the question has an answer, including when the answer is no. A proof of concept that produces a maybe was scoped wrong, usually because the success criterion was never written down as a number.
Typical scale: days rather than weeks, and the smallest of the four by a wide margin.
Prototype: is this the right shape
A prototype answers a design and comprehension question. Do people understand this. Does the flow match how they actually work. Which of these two approaches causes fewer mistakes.
It can be clickable screens with no functioning software behind them, which is usually the efficient version. Its value is that people argue productively about a screen and unproductively about a description of a screen.
Prototyping the whole application is the common waste. The parts where everyone already agrees do not need a prototype. Build it for the two or three flows that carry genuine disagreement.
A prototype cannot tell you whether anyone wants the product. People are agreeable about hypotheticals, and a prototype only ever tests a hypothetical.
Pilot: does this hold up in our environment
A pilot answers an operational question. Does this survive real data, real users, real volume and the existing systems it has to sit alongside.
It is real software, deployed, used by a limited group doing actual work. Limited by scope rather than by quality, because a pilot that fails for reasons of unfinished engineering has told you nothing about the thing you were testing.
This is where most enterprise AI work goes wrong. MIT's 2025 research covering more than 300 deployments found that 95 percent of enterprise generative AI pilots produced no measurable financial return, with integration and organizational learning identified as the cause rather than model capability. McKinsey's State of AI survey finds around a third of organizations have begun scaling AI and 7 percent describe it as fully scaled, which describes an enormous population of pilots that never became anything.
The pattern behind those numbers is worth naming: pilots run in conditions carefully arranged to make them succeed, then fail when the conditions become real. A pilot that avoids the hard integration is not a pilot, it is a demonstration.
MVP: should we build the rest of this
An MVP answers a commercial question. Given a real product doing a real job, do people use it, pay for it, or change their behavior because of it.
It has to be complete enough along one narrow path that a user can get value without help. Breadth is what gets cut, never the depth of the one thing it does. A product that does eight things badly answers nothing, because every negative result is explained away by the poor quality.
An MVP is the largest and most expensive of the four, which is why building one to answer a feasibility question is such a costly mistake.
Choosing between them
Write down the question you actually have, then pick the cheapest instrument that can settle it.
If you do not know whether the technology can do it, that is a proof of concept. If you do not know whether people will understand it, that is a prototype. If you do not know whether it survives your systems and your data, that is a pilot. If you do not know whether anyone wants it, that is an MVP.
Two failure patterns account for most of the waste. Building an MVP to answer a feasibility question, which spends product money on an engineering unknown. And running a pilot that carefully avoids the integration, which spends real money to prove something everyone already believed.
What each costs
A proof of concept is contained work, typically a few days, and sits at the small end of our $5,000 to $15,000 range. Prototypes are similar in scale when limited to the flows that carry disagreement.
A pilot costs more than people expect, because the value of a pilot is entirely in the parts that are hard: real data access, real permissions, real integration. Those are the same components a production system needs, so a pilot built properly is largely reusable, and a pilot built to be cheap is largely disposable. Ours generally sit in the $5,000 to $15,000 band, and higher when the data access is genuinely difficult.
An MVP starts at $18,000 with us for a real first version with its own data model. Discovery to establish which of the four you actually need starts at $3,000 and is credited toward whatever follows.
Frequently asked questions
What is the difference between a proof of concept and a prototype?
A proof of concept answers whether something is technically possible and is built to be discarded. A prototype answers whether the design makes sense to people and often contains no working software at all.
Is a pilot the same as an MVP?
No. A pilot tests whether a solution works inside your environment, usually for an internal problem you already know you have. An MVP tests whether people want the product at all. A pilot can succeed completely while the underlying idea remains commercially worthless.
Why do so many AI pilots fail?
MIT's 2025 research put the figure at 95 percent producing no measurable return and identified integration and organizational learning as the cause. The recurring pattern is a pilot arranged to avoid the difficult data access, which then cannot be scaled because the difficult part was never done.
Can a proof of concept become the product?
It should not. Proof of concept code is built without the error handling, permissions and structure a product needs, and keeping it means carrying those omissions into production. Reuse what you learned rather than what you wrote.
How do I know which one I need?
Write the question in one sentence and name what result would change your decision. If you cannot write that sentence, none of the four will help yet, and the missing work is scoping.
Where to start
If you have a question you want settled and are not sure which of the four settles it, that is what our audit produces: one problem, picked and scoped, with the cheapest instrument that answers it.