A proof of concept is not a small version of the product. It is an experiment with a single job: to make one uncertain thing certain, as cheaply as possible.
If you cannot name the question in one sentence, you are not ready to build one.
When a PoC is worth the money
Figure 01 — where a PoC earns its cost
Build one when at least one of these is true:
- Technical feasibility is genuinely unknown. Not “hard”, but unknown — a performance ceiling, an unproven algorithm, a model’s accuracy on your actual data.
- An integration is opaque. Third-party APIs with poor documentation, legacy systems with undocumented behaviour, hardware in the loop.
- A commitment is expensive and hard to reverse. Platform choice, vendor lock-in, a data model that will be difficult to change later.
- Stakeholders disagree on something testable. A working artefact ends arguments that slide decks extend.
When it is not
- The uncertainty is about desirability, not feasibility. Talk to users; do not build.
- The technology is well-trodden. Building another CRUD service proves nothing.
- The PoC is being used to justify a decision already made. That is theatre with a budget line.
Scope it to one falsifiable question
Write it down before starting, in this shape:
We believe X is possible under constraints Y. We will know within N weeks because Z will be measurable.
Concrete examples:
- “We can extract structured line items from these supplier invoices at above 90% field-level accuracy on our historical set, within three weeks.”
- “We can serve availability lookups under 150ms at 5,000 requests per second on this data model, within two weeks.”
Both are falsifiable, time-boxed and measurable. That is the entire test of a good PoC brief.
Rules that keep a PoC honest
Figure 02 — the four-week shape
- Time-box hard. Two to four weeks. If it needs longer, the question is too broad — split it.
- Use real data. Synthetic data hides exactly the problems you are trying to surface.
- Skip everything not under test. No auth, no admin panel, no polish, unless one of those is the question.
- Write down the answer. The deliverable is a decision and its evidence, not a repository.
- Agree in advance what a “no” means. A PoC that cannot fail is not an experiment.
The failure mode to watch for
Figure 03 — how a PoC becomes production by accident
A successful PoC has a way of being demoed to an executive, who asks why it cannot go live next month. Deliberately unfinished code then acquires users, and eighteen months later it is a production system nobody chose.
Two defences: label it clearly as an experiment in every demo, and get the rewrite-versus-harden decision made explicitly at the end — with the cost of hardening estimated while the context is fresh.
What comes after
A PoC that answers “yes” should produce a scoped MVP plan with the technical risk now removed. A PoC that answers “no” has just saved you the cost of finding out later, which is the cheaper of the two outcomes and the one worth celebrating properly.