One question, answered early
Every ambitious technology initiative carries one question that is cheaper to answer early than late: can this actually be built, with our data, our systems, and the technology available today? A proof of concept (PoC) exists to answer that question and nothing else.
It is not a prototype, not a pilot, and not a first version. It is a small, time-boxed experiment with a single technical hypothesis, a definition of what proving it looks like, and a decision waiting on the result.
Why organisations skip it, and pay for it
The pressure to move quickly leads teams to start building the product and discover the blockers in month four: a third-party API that cannot do what the vendor claimed, a data source too incomplete to train on, a latency floor that makes the user experience impossible. By then the budget is committed, the stakeholders are invested, and the honest conversation is harder.
A PoC moves that conversation to week two, when it costs a fraction of the price and nobody has to defend a decision they have already made.
PoC, prototype, MVP
The terms get used interchangeably. They answer different questions and are built for different audiences.
| Proof of concept | Prototype | Minimum viable product | |
|---|---|---|---|
| Question | Can it work technically? | How should it look and flow? | Will customers use and pay for it? |
| Focus | Core logic, integrations, hard constraints | Interface and user journey | A usable slice of the real product |
| Audience | Technical and executive decision-makers | Designers, stakeholders, investors | Early customers |
| Code quality | Disposable | Superficial | Production-grade |
| Output | A go or no-go decision | A design direction | A product in market |
A team that builds a prototype when it needed a PoC learns how the thing should look before learning whether it can exist. A team that builds an MVP when it needed a PoC spends production money on an open question.
Scoping one that gives a clean answer
The quality of a PoC is decided before it starts. In our work, the ones that produce a usable decision share five properties.
One hypothesis. "Can we extract structured data from these contract PDFs at 95% accuracy" is a PoC. "Can we build an AI contract platform" is a programme.
Success criteria written down first. Accuracy, latency, throughput, cost per transaction, whichever matters. Agreed with the people who will make the decision, before any code.
Real data, or an honest substitute. A PoC on clean sample data proves the vendor's demo. The hard part is usually the data you actually have.
A fixed time box. Two to four weeks is typical. If the question cannot be answered in that time, the question is too big.
A decision owner. Someone who has agreed in advance what happens on each outcome: proceed, pivot, or stop.
What a good PoC is allowed to be
Ugly. Temporary code, hard-coded values, no interface beyond what the test needs. Speed matters more than polish because the artefact is the answer, not the software. The deliverable is a short report: the hypothesis, the method, the results against the criteria, the blockers found, and a recommendation with the cost and risk of the next stage.
Making the result stick
The failure mode after a PoC is not technical. It is organisational. The result says "not feasible as specified" and the project continues anyway, because momentum, sunk cost or a senior sponsor outweigh the evidence.
Three things reduce that risk:
- Involve the decision-makers in setting the criteria. People accept a result they helped define.
- Report blockers with options. "Not feasible" is a dead end. "Feasible if we change the data source, at this cost" is a decision.
- Treat a negative result as a success. It saved the organisation the cost of finding out later. Say so.
Where Good Analysis fits
We scope and run proofs of concept for organisations weighing an AI, data or platform investment: defining the hypothesis, building the experiment, and writing the decision paper. It is usually the first step in our AI Readiness and Platforms & Process work, and the cheapest way to find out whether a bigger project deserves to exist.
