Proof of concept, pilot, MVP. The three words get used interchangeably in the same meeting, and the confusion is expensive: each answers a different question, each ends differently, and scoping one as though it were another is how a two-week experiment turns into a two-quarter commitment.
The three questions
A proof of concept asks: can this work at all? It can be answered on sample data, in a lab, usually by one engineer. Nobody outside the project needs to see it.
A pilot asks: does this work here, with our data and our people? It can only be answered inside the business, with real inputs and real users. It is as much an organisational test as a technical one.
An MVP asks: will people use this, and is it worth maintaining? It is the first version of a product you intend to keep, support and improve.
The distinction that matters most: the first two are experiments you plan to throw away. The third is an asset you plan to own. That difference should be reflected in how they are built — a PoC written to production standards is wasted money, and an MVP written to prototype standards is a liability you will pay for repeatedly.
Choosing between them
- If the technology is unproven for your case, start with a PoC. Unusual data formats, poor published accuracy in your domain, or physical conditions no specification captures.
- If the technology clearly works and the question is fit, skip the PoC and pilot. Paying to confirm something the industry settled two years ago is a common and avoidable expense.
- If both feasibility and fit are established and the question is adoption, you are building an MVP. Scope, staff and budget it as a product, not an experiment.
The most common mistake
Running a PoC and treating the result as though it answered the pilot question. A proof of concept succeeds on curated data by design — that is what makes it cheap. When the same approach meets production inputs with their missing fields, inconsistent formats and edge cases nobody documented, the accuracy that looked settled becomes an open question again.
This is not a failure of the PoC. It is a failure to notice that a different question was still unanswered.
The second most common mistake
Letting a successful experiment become the production system by default. Nobody decides to do this; it happens because the prototype works, people start relying on it, and rewriting something that already works is a hard budget conversation.
The result is a system with no tests, no error handling and no documented owner, sitting in the middle of a process it was never designed to support. Rewriting is almost always cheaper than untangling — and far cheaper if the decision is made deliberately at the end of the pilot rather than reluctantly eighteen months later.
What each one should cost
At Crux Digits: a €2,500 audit establishes which of the three questions you are actually facing, which is worth doing first because the answer is frequently "none — a conventional script solves this". A €20,000 proof of concept runs four to six weeks on real data. Production starts from €50,000.
If a supplier quotes the same shape of engagement regardless of which question you are asking, that is worth noticing.