Reviewed by LAB/02 editorial check (AI-assisted)
Prototype or proof of concept: which question must you answer first?
Choose the right pre-build experiment by separating customer understanding from technical feasibility, scope and evidence.
AI-generated / AI-editedThe word experiment hides two different decisions
A prototype and a proof of concept can both look like an early version of a product, but they answer different questions. A prototype asks whether people can understand and use a proposed journey. A proof of concept asks whether a difficult technical idea can work under the constraints that matter to the business.
Confusing them creates expensive evidence. A polished prototype cannot prove that a data connection, rules engine or integration will be reliable. A technical spike cannot tell you whether a customer understands the offer. Name the uncertainty before choosing the artefact.
Choose a prototype when the interaction is uncertain
Use a prototype when the risk sits in the customer journey: what a person sees first, which option they choose, what information they need and whether the next step feels clear. Keep the scenario narrow enough to observe. One realistic task is more useful than a catalogue of screens that nobody knows how to test.
A good prototype describes what is simulated. It can show a booking, approval or payment step without connecting to real accounts or taking real money. That boundary protects the test from creating false confidence and gives participants a concrete experience to react to.
Choose a proof of concept when the hard part is underneath
A proof of concept is appropriate when the decision depends on a technical hypothesis: can two systems exchange the required data, can a rule be evaluated quickly enough, can a workflow handle the exceptional cases, or can a model produce an output that is useful under real constraints? The work should isolate that question rather than build a small version of everything.
Define the evidence before coding. It might be a working demonstration, a latency threshold, a list of failure modes or a decision about whether to continue. A proof of concept is successful when it reduces uncertainty, including by showing that an approach should be changed.
Put the decision into the brief
Write one sentence beginning with ‘We need to learn whether…’. Then list the smallest test, the data or assumptions it needs, the people who will review it and the decision that follows. Record what the test does not cover so that a promising result is not mistaken for production readiness.
If both customer and technical uncertainty matter, sequence the work. A short prototype can expose the journey before engineering effort is spent; a focused proof of concept can then test the riskiest dependency. Scope, acceptance criteria and ownership should be agreed separately before paid delivery begins.
AI-generated / AI-edited