Proof of concept (PoC)
Also called PoC, spike, technical spike.
A small, often throwaway build that tests whether one risky technical idea can work at all.
Last updated
What it is.
A proof of concept answers one question: can this be done? It might test whether a model can read a messy invoice, whether two systems can sync fast enough, or whether a device's Bluetooth link holds up in a warehouse.
It is not a clickable prototype, which tests whether people understand a design, and not an MVP, which real users use. A PoC usually has no proper interface, no security and no tests, and that is fine because it is not meant to ship.
Why it matters
Some projects hinge on one uncertain technical piece. Spending a week or two on a PoC before committing the full budget tells you whether that piece works, how hard it is, and what it costs to run, while it is still cheap to change plan.
In a product build
A PoC fits inside discovery, before the first milestone. Its result decides whether the hard part is built as planned, built a different way, or dropped.
Common mistakes.
- 01
Shipping the PoC code to production because it worked. It was not built to last.
- 02
Testing with clean sample data instead of the messy real data the system will see.
- 03
Not deciding beforehand what result counts as success.
Work it out with a tool.
Related terms.
- Clickable prototypeA set of linked screens you can click through, built to test a design before the real software exists.
- MVP (minimum viable product)The smallest version of a product that real users can use, built to test whether the core idea works.
- Discovery phaseThe short stretch before a build where the team works out the problem, the users, the scope and the rough cost.
- LLM evals (evaluations)Repeatable tests that score how well a model, prompt or AI feature does a specific task.
Guides and pages
Browse the full glossary or read answers to common questions.
