Should You Test Before You Build? A Founder's Guide to Prototypes, Proofs of Concept and Pilots

Overview

You are about to pay for a build, with one question open: will people follow the design, can a technical idea be made to work, or will it hold up in real use? Prototypes, proofs of concept, pilots and first releases answer such questions before — or instead of — committing to the whole product. They are options to choose between, sometimes combined — not stages in a set order.

Key Points

• Name the decision and its unknown first: the right test is the one whose evidence bears on it.
• The four approaches answer different questions; they can overlap or run in any order. There is no ladder.
• Exploratory code is not automatically production-ready, but not automatically rubbish either: reuse follows assessment, hardening and verification.
• A test answers only for its conditions: live data where the question needs it, authorised synthetic or masked data where it does not.
• Agree the question, pass mark, participants, support, end date and the code's fate beforehand.
• Record what the test did not settle: one clear result leaves the other unknowns open.

The short answer

Test before you build when a specific unknown blocks a decision. Pick the approach that can evidence it, agree what result would change your decision, and fix a decision date. If no open question would change what you do next, a test adds delay, not information.

Begin with the decision the test has to inform

Start from the decision: “We will commission the full build if the records problem is solvable.” Then name the unknown it turns on — understanding, feasibility, operations, or use. The GOV.UK discovery phase makes the same separation, understanding the problem before building starts. If the unknown cannot be pinned down, the gap is in the scoping — our guide to SaaS development planning covers the decisions to settle first.

Four approaches, matched to four kinds of uncertainty

Nothing here is a sequence: a team might pilot a bought product with no prototype at all. Cost does not follow the labels either — each test costs what its scope costs, and a narrow first release can be smaller than a long supported pilot. Choose by the uncertainty.

Prototype: can people follow the design?

A prototype represents the product — sketches, linked screens or a coded mock-up — for people to try tasks against. The GOV.UK Service Manual's guidance on making prototypes describes prototypes as a way to test designs before committing to building the real thing. A prototype can contain working code; its purpose — testing understanding, not delivering a service — is what defines it. Concentrate on the flows where behaviour is in doubt. Read results modestly: reactions are early evidence about the design. Prototype sessions can provide early signals of interest, but they do not establish sustained use.

Proof of concept: does a technical idea hold up?

A proof of concept is a bounded piece of building that answers one technical question: whether a phone camera can read your warehouse labels in poor light, or whether two systems stay in agreement when a connection drops mid-update. The point is the answer, not a head start. It can end in yes, in no, or in “not under the conditions we tried”. That third result is weaker evidence, not meaningless — and not automatic proof the question was badly set: performance may sit near a boundary, or conditions varied beyond anyone's control. Then decide: narrow and retest, proceed differently, or stop.

Pilot: does it work inside your operation?

A pilot puts real software into real use by a limited group: actual work, your systems, your permissions. The shape resembles the GOV.UK Service Manual's private beta: limited users, supported while the team learns and improves. A founder's pilot needs the same named help for users whose work is at stake — our guide to what software maintenance actually includes discusses support in that context.

A pilot's conclusions cover only what it exercised. If the question is whether it survives your data and integrations, the messy records and difficult integration belong inside it. But production data is not compulsory where the question allows less: authorised synthetic, masked or minimised data can serve, if it represents the conditions that matter, access is controlled, and it is disposed of properly. An early-ending pilot still yields evidence for the part that ran.

First release: will people use it for real?

A first release is a working product in front of real users. Keep its scope narrow — one job done completely, so a user can finish unaided — because a release attempting everything makes results hard to read: a failure could belong to any part. Distinguish scope (what it does) from rollout (who receives it first): a limited rollout to one team is a distribution decision, not a smaller product. Nor is a first release automatically the costliest option; cost follows scope. Choose it when the unknown is use itself — see our guide to web and mobile MVP planning for shaping that first version.

A worked example, kept hypothetical

Suppose, hypothetically, a small property-maintenance firm is considering a job-tracking tool. Two unknowns block a build decision. The first is understanding: will office staff and field workers follow the same job flow, or will field workers abandon a desk-designed flow? That is a prototype question — clickable screens for the disputed flows, tried with real staff.

The second is technical: can the firm's existing accounting records be reconciled with the new tool's job records each night, without manual repair? That is a proof-of-concept question — a bounded build judged against a written pass mark. This example is not a client and promises no result. Even if both pass, whether anyone will keep using the tool remains unproven — a pilot or first-release question, recorded as open rather than assumed.

Agree the test before anyone builds it

A test without a written agreement is a demonstration with a budget. Agree these points first:

• The question in one sentence, and the result that would change your decision — including what counts as a stop.
• Who and what it covers: users, workflows, systems and data in scope — and out.
• What good looks like: the tasks testers attempt, and how success is judged.
• The data arrangements: live, synthetic, masked or minimised; who may access it; how it is protected and disposed of.
• Who supports test users, and what happens to their work if the test ends early.
• The findings, designs and code afterwards: what you keep, who owns it, and how kept code is assessed before reuse.
• The end date and decision meeting: when it stops, who decides, and the options.

Our guide to fixed price versus time and materials explains why a fixed price covers a defined scope only — what a good test brief provides.

Three ways a test misleads

A misleading result is worse than none, because it feels like evidence. Three traps:

A polished prototype is read as a finished product

The more finished a prototype looks, the more easily stakeholders read it as a promise: dates get discussed and budgets assumed around a mere question. The Nielsen Norman Group's comparison of low- and high-fidelity prototypes notes that rough prototypes invite change, while polished ones invite expectations of shipment. Match the finish to the question being tested, and keep the rest visibly provisional.

Pilot conditions are sheltered, but the conclusions are not

A pilot run with hand-picked users, cleaned data and the hard integration postponed produces genuine evidence — about those sheltered conditions. The misleading step is reporting it as rollout evidence: if difficult parts were excluded to answer a narrower question, say what was answered and what was left for later.

Exploratory code is carried into production unexamined

The risk is not reuse; it is reuse by default, because it exists. Code written quickly to answer a question may skip error handling, access controls or capacity — or may be sound where it matters. Nobody knows until an engineer assesses it against production requirements, hardens what falls short and verifies the result. Agree that step in advance: contractual terms address rights subject to applicable law and existing rights; they do not establish production readiness.

What a test leaves unsettled

Prototype sessions show whether people can follow a design and hint at interest; they cannot show sustained use. A pilot shows behaviour for one group — often the most motivated — over one period. A proof of concept shows an idea working under the conditions tried, not at every scale. The honest output of any test is two lists — what is now known, and what is still open — so write both down at the decision meeting.

Practical next steps

If a build decision has one specific unknown in it, work through these steps:

• Write the decision in one sentence; name the unknown: understanding, technical, operational or demand.
• Choose the approach whose evidence matches the unknown; note what it leaves open.
• Agree the pass mark, participants, data, support, code and ownership terms, and the decision date — before anyone builds.
• Run it under conditions representative of the question: realistic tasks; data and systems as real as the question requires.
• Hold the decision meeting on the agreed date: build, change direction, test once more, or stop.

If you cannot write the decision sentence, do the scoping first.

Frequently asked questions

Do I need all four tests?

No — they are not a set to complete, and projects combine them in different orders: a prototype with no proof of concept, a pilot of bought software with neither. Use the one or two bearing on your largest unknown.

Can test code become part of the product?

Sometimes, deliberately. Exploratory code is written under different priorities, so it is not automatically production-ready — but not automatically unusable either. The route to production is assessment against production requirements, hardening where it falls short, and verification under real conditions. A pilot can evolve the same way; it need not meet every eventual requirement from day one. An agreement governs rights in the code, not its suitability — settle in advance who decides on reuse, and against what standard.

Who owns the code and findings from a test?

There is no single default answer. Ownership, and what you may do with the code and findings, depend on the applicable law and on the terms you validly agree — both against pre-existing rights, including the developer's own material and third-party components. Settle it before the test starts. Our guide to IP, escrow and handover explains how payment, ownership and access come apart. This is general information, not legal advice.

How long should a test take?

There is no standard duration; it follows the question and the conditions to assemble. Distrust any test with no end date: a test without an end is a build by another name. For scale only, the GOV.UK Service Manual describes its government alphas as lasting six to eight weeks: a government programme, not a rule for your project.

Sources

Read in full on 27 October 2026 (Asia/Karachi); technical guidance comes from these primary sources.

GOV.UK Service Manual — How the discovery phase works. Published 4 August 2016; updated 21 June 2021. Understanding the problem before building.

GOV.UK Service Manual — How the alpha phase works. Published 4 August 2016; updated 8 May 2019. Testing the riskiest assumptions first.

GOV.UK Service Manual — Making prototypes. Published 18 October 2016. Exploring and testing designs before building the real thing.

GOV.UK Service Manual — How the beta phase works. Published 4 August 2016; updated 19 February 2021. Private beta: limited users, support and iteration.

Nielsen Norman Group — UX Prototypes: Low Fidelity vs. High Fidelity. Published 18 December 2016; updated 10 December 2025. How fidelity changes what people expect.

Weighing a build with an open question? Our project cost calculator gives an indicative cost and timeline range from scope and complexity, and you can discuss your project with us.