Proof of concept: the cheapest way to discover you are wrong

A proof of concept (PoC) helps an organisation test whether an idea can work before committing to a larger investment. However, the term is now used so loosely that many PoCs prove very little at all. This article explains what a PoC is, how it differs from other early development activities, and how to design one that genuinely improves a decision.

Martti Asikainen & Dr Umair Ali Khan | 12.10.2026 | Photo created with AI

Imagine a company investing in an AI tool to process customer purchase orders. For a few existing customers, the results look promising. The tool extracts the order details, calculates individual item prices using the customer’s pricing table, and generates an order draft.

However, the company soon discovers that each new customer brings a different purchase-order format and pricing table. Adapting the system to these variations takes considerable work, and errors remain difficult to eliminate. Employees also discover that checking the AI-generated draft against the original purchase order and the applicable prices takes as much time and effort as preparing it manually.

The details vary, but the pattern is familiar. A promising idea travels straight from the slide deck to the build, and its riskiest assumption is discovered last, when it is most expensive to fix. Ideas are cheap. Turning them into something that works is considerably harder. And definitely more expensive. Somewhere between the two sits a modest tool that could have saved a huge investment. This tool is called a proof of concept.

Not a failure of nerve, but of process

It is tempting to blame the team in that scenario. However, the team did test the idea. The problem was that the test did not reproduce the conditions under which the system would need to work. Such gaps can persist when organisations reward visible progress and allocate budgets for development without requiring evidence that the critical assumptions hold. A useful process makes those assumptions explicit and requires them to be tested before a larger commitment.

A PoC provides a structured way to investigate these uncertainties. However, its meaning is not always clear in practice. In a mapping review of mental health implementation research, Woods et al. (2024) found that 95 per cent of the 22 included studies used the term for work that did not correspond to the PoC stage in the Technology Readiness Level (TRL) framework. This illustrates how the label can obscure what a study has actually established.

A workable definition is this: a PoC is a limited experiment designed to determine whether the essential idea behind a proposed solution is technically or scientifically viable. The important word is limited. Think of it as tasting the sauce before you cook for forty guests. You are not testing the menu, the table settings or whether people will enjoy the evening. You are testing the one thing that, if it fails, makes everything else irrelevant.

Prototype shows, proof of concept answers

A PoC tests a specific feasibility question. For example, a company considering an AI customer-support assistant could test whether it can answer representative questions accurately using approved support documents and recognise when the documents do not contain an answer.

A prototype is an early representation of a proposed solution, used to explore its appearance, behaviour or technical operation. For the same assistant, a prototype might provide a simple interface where employees enter questions, read answers and inspect supporting sources. A prototype can also be built as part of a PoC to test a particular assumption.

A pilot examines how a solution operates in a limited real setting. The company could introduce the assistant to a small support team, with employees reviewing its answers before sending them to customers. The pilot could examine whether it saves time, fits existing workflows and creates additional checking work.

A feasibility study considers broader technical, financial, regulatory and organisational questions. For the assistant, it could assess whether expected time savings justify development and operating costs, whether customer data can be handled appropriately, and whether the company has the resources to maintain it. These activities can inform one another and do not always follow a fixed sequence.

NASA’s Technology Readiness Level framework makes the position clear. It describes nine levels of maturity, from basic scientific principles at level one to a system proven in operation at level nine. Proof of concept sits at level three, described as analytical and experimental proof of concept for critical functions (Manning, 2023; NASA, 2023). In other words, a successful PoC has climbed a third of the ladder. It is an early milestone, not the finish line.

What should PoCs actually test?

The value of a PoC is best understood in terms of the economics of learning. If a €10,000 experiment stops an organisation from spending €500,000 on something unworkable, it has paid for itself fifty times over. Robert G. Cooper’s Stage-Gate model formalised this logic decades ago, suggesting that innovation moves through stages separated by gates, where evidence decides whether a project continues or stops (Cooper, 1994; 2008). A PoC is simply a well-placed gate.

The discipline lies in choosing what to test. A team developing a wearable health sensor might face dozens of open questions about battery life, comfort, wireless transmission, manufacturing cost, regulation and customer demand. Trying to answer them all turns a small experiment into a full development programme. A good PoC picks the single assumption that could sink the project. Can the sensor reliably detect the signal at all?

In practice, the useful starting question is not “What should we build?” but “What do we need to learn?” From there, the team builds the smallest experiment that answers it, without polished interfaces or production infrastructure. Crucially, it defines success before the test begins: for instance, 95 per cent extraction accuracy for the purchase-order processing use case under defined laboratory conditions. Otherwise, the goalposts have a habit of drifting once the results arrive.

The team should also agree on the test data, evaluation method, time limit, budget and person responsible for the next decision. Test cases should reflect the intended operating conditions and remain separate from the data used to develop or adjust the solution. The final record should state what was tested, what was observed, what remains uncertain and which next step the evidence supports.

For an AI customer-support assistant, a PoC should evaluate at least 100 representative questions against current, approved support information. The questions should include routine cases, difficult cases and cases requiring escalation, and should be kept separate from those used to adjust the prompts. Support specialists could assess the responses using predefined criteria for correctness and completeness. A reasonable threshold might require at least 90 per cent acceptable responses, no critical misinformation observed in the test set, and correct escalation for every case designated as requiring it. Meeting these criteria would support further testing, rather than establish that the assistant could never make a serious error.

When everything is a proof of concept, nothing is

So far, so sensible. But here is where the easy story starts to fray. The popularity of the term has produced a kind of PoC inflation. A slide deck gets called a proof of concept. So does a polished prototype, a small pilot, even a promising conversation with a customer. Each label carries an implied claim: that something has been proven.

That claim travels upwards. When a steering group hears “the PoC was successful”, it reasonably assumes the hardest technical question has been answered. Often, it has not. In our work with organisations, the PoCs that disappoint later are rarely the ones that failed. They are the ones that quietly tested the convenient part and left the risky assumption untouched. Recent software engineering research makes a similar point, noting that although PoCs are widely used, their definitions and methods remain inconsistent, and arguing for a more systematic approach to planning and decision-making (Antognolli & Petrillo, 2026).

Again, this is less about individual judgement than about incentives. A demonstration that impresses is easier to present than one that might fail, and many organisations still budget for the former. There is a second trap too. A technically successful PoC says nothing about customer demand, profitability, scalability or regulatory approval. A technology can work perfectly and still make a terrible business.

From "can we?" to "should we?"

Perhaps the most useful way to see a PoC is as a hinge between two questions. Before it, the question is whether an idea can work. After it, the question becomes whether, given what we now know, we should continue. The real product of a PoC is therefore not the demo, the model or the prototype. It is knowledge, and the better decision that knowledge makes possible.

That also means a PoC can succeed even when the technology fails. If the experiment shows that an approach cannot reach the required threshold, it has done exactly its job. The answer might be yes, not yet, or no. All three are worth having. What is not worth having is a vague “looks promising” that nobody can act on.

A useful habit, then, is to treat any proof of concept declared a success in your organisation as a claim to be examined rather than a result to be celebrated. Three questions usually suffice: which assumption was actually tested, what counted as success before the test began, and which decision the results are meant to inform.

Clear answers mean the PoC has earned its name. Vague ones suggest it may simply have been a well-made demonstration. The real failure is not discovering that an idea does not work. It is spending significant resources assuming that it will. The sooner that assumption is tested, the less it costs to be wrong.

Testing your own idea

If your organisation has an AI idea but is unsure whether its core assumption holds, a carefully scoped PoC is often the sensible first step. It can help you investigate that uncertainty using your own data, requirements and operating conditions. The Finnish AI Region (FAIR) offers enterprises, SMEs, midcaps and public-sector organisations free proof-of-concept and prototyping services for precisely this purpose.

The aim is to help organisations test whether artificial intelligence and other advanced technologies can work in their own context, before they commit larger resources. You can find more information on our services page.

Whether you work with FAIR or conduct the experiment independently, its value comes from what you learn and how you use that knowledge. A positive result may justify further development. A negative result may lead to a different approach or prevent an unnecessary investment. In either case, the next step should follow from the evidence, with a clear understanding of what still needs testing.