What is a proof of concept (PoC)?

Ahead of any project carrying a major technical unknown sits a question that meetings cannot settle: can it actually be done? Can we automatically read the odd file format produced by a German machine built in 1998? Will AI cope with our handwritten documents? Will the integration with the accounting system survive our real volumes? A proof of concept is that answer bought cheaply — a small test, days or a few weeks on a limited budget, built exclusively to check the unknown, with no pretence of being a product. The interface can be ugly, the edge cases ignored, the whole thing discarded afterwards; only the documented verdict on the stated question matters. The distinction from its relatives is a permanent source of confusion in proposals. A PoC verifies technical feasibility. A prototype verifies form and experience, often with no real functionality behind it. An MVP verifies the market, as a minimal but genuine product in customers’ hands. For a buyer, the PoC is above all an instrument of contractual risk management: on projects with large unknowns the healthy structure is a paid proof of concept with success criteria written in advance, followed by the decision on the main project. Two disciplines separate a useful PoC from validation theatre — success criteria defined beforehand and measured on real data rather than the clean examples in a demo, and honesty about a negative verdict, because a test proving something cannot be done economically has just repaid its cost many times over.