What is a proof of concept actually for?
A technical proof of concept is for testing whether a specific approach can satisfy a consequential constraint before a team commits to the wider product. It should answer one question that would otherwise force an expensive assumption: whether a difficult integration is viable, a performance target is realistic, a device can communicate reliably, or a proposed architecture can preserve a critical rule.
Start with the decision, not the demo
Write down the decision that depends on the result. For example: proceed with a provider, keep an offline workflow, choose a delivery pattern, or change the first-release scope. If a result would not alter a real decision, the work is more likely to be exploration or presentation than a proof of concept.
Choose the uncertainty with the largest consequence
Not every unknown deserves a technical experiment. Prioritise the assumptions that are both uncertain and costly to discover late: a dependency outside the team's control, a hard operational limit, an unfamiliar protocol, an irreversible migration step, or a requirement that changes the product's core shape.
Which risks are worth proving early?
Prove risks that cannot be settled by a sensible design discussion, existing documentation, or a small review of the current system. Good candidates include behaviour at a real system boundary, an uncertain performance characteristic, compatibility with a device or provider, an authentication constraint, or recovery after a deliberately induced failure.
Test the constraint rather than its appearance
A polished screen connected to mocked data can show that an idea is understandable, but it cannot prove that a provider accepts a request, a queue preserves work, or a local device recovers after a connection drops. Use the least elaborate implementation that exercises the real constraint.
Keep product validation separate
A proof that something can be built is not evidence that people need it, will understand it, or will pay for it. Treat user research, workflow discovery, prototype testing, and technical feasibility as related but distinct sources of evidence. Combining them under one attractive prototype often hides what has actually been learned.
What evidence makes the result credible?
Credible evidence is observable, repeatable enough to inspect, and tied to a stated acceptance condition. Define what must happen, under which conditions, and what would count as failure before implementation begins. Capture the result in a short record that another decision-maker can understand without relying on the builder's memory.
State an acceptance condition
A useful condition is specific: the system can process a representative record, preserve identity across a hand-off, recover a delayed response without duplicate work, or complete an operation within an agreed boundary. 'It seems to work' cannot guide a product decision because it does not say what was tested or what remains unknown.
Include the difficult case
Exercise one or two conditions that make the approach fail or degrade: invalid input, a missing field, a repeated request, a delayed provider response, a disconnected device, or an expired credential. The point is not to simulate every future problem; it is to learn whether the proposed boundary behaves honestly when the easiest path breaks.
How small should a proof of concept be?
Make a proof of concept only large enough to produce the evidence the decision requires. It may be a contained script, an isolated service, a thin vertical slice, or a controlled test against a real dependency. It should deliberately omit styling, administration, broad permissions, and surrounding features unless they are part of the risk being tested.
Avoid accidental product development
A proof of concept becomes expensive when it quietly acquires production expectations: reusable interfaces, full user management, deployment polish, edge-case coverage, or permanent data. That work can be valuable, but it should be explicitly promoted into a product slice with its own scope, ownership, and delivery plan.
Use representative inputs
Small does not mean artificial. Use realistic payloads, limits, permissions, and failure conditions where possible. A test based on a convenient toy example can produce a technically correct answer to a question the product does not actually need to ask.
What should happen after the experiment?
End a proof of concept with a decision, a record of remaining uncertainty, and a clear disposition for the code and credentials involved. The result might justify proceeding, changing direction, narrowing scope, running a second targeted experiment, or declining an approach. A negative result is useful when it prevents a larger commitment to the wrong path.
Record the boundary of the finding
Describe what the test demonstrated and what it did not. A successful provider call does not prove operational volume; a fast local query does not prove production performance; a one-user device test does not prove fleet management. This prevents a narrow observation from becoming an overly broad architectural claim.
Retire or deliberately promote the artefact
Remove temporary data, credentials, and environments when the experiment ends. If part of the work should become product code, bring it through normal design, security, testing, and deployment review rather than treating an exploratory shortcut as a production foundation.