You’ve got an idea for a custom tool, or a way to connect two systems that need a person with a keyboard in between. A supplier has quoted for the whole thing, and the number is large enough that you’d like to know it’ll work before you sign. That’s what a prototype is for. Too often it gets bought as a cheap, rough version of the finished product, which defeats the point. If you’re a new business, this is one of the decisions our startup services page covers.
A prototype is a question with some code around it
The useful kind exists to answer one question you can’t answer by thinking about it. Can the supplier’s system accept what we need to send it? Will the thing still respond when two hundred people use it at once? Will the person who has to use it every day put up with it?
Notice that none of those asks for a small version of everything. A small version of everything tells you little, because the risky part is usually one awkward corner, and a prototype that builds a login screen, a menu and a report around it has spent most of its time on things that were never in doubt. The GOV.UK Service Manual makes a similar point about its alpha phase, telling teams to identify their riskiest assumptions and test them, and saying alpha is finished when a prototype is substantial enough to help make a decision, which can include stopping altogether. The best test of a prototype brief is whether you can write the question on one line. If you can’t, you’re probably describing the first phase of the product, which is fine, but it’s a different thing to buy.
Choosing the question
Start with what would make you stop. If the whole idea falls over when one assumption turns out to be wrong, that assumption is the question, and the same few kinds come up again and again. Can it be done at all with the tools and access you have? Will another system let yours talk to it, which depends on whether it offers an API, an agreed way for one program to ask another for something? Will it keep up with real volumes? Will people use it, which only people can tell you? And what will it cost each month to host, patch and support? That last one matters because a tool that’s cheap to build and dear to run is a poor bargain, and it belongs in your IT budget before you commit, not after.
If you’ve several candidates, rank them by how bad the answer would be and how little you know. The question that’s both frightening and unknown goes first.
Deciding when it’s finished
Time-box it. Agree a short fixed period, a few days or a couple of weeks depending on the question, and treat it as a limit, not a target. Open-ended prototyping drifts, because there’s always one more thing to try, and each extra feature makes the thing feel more like a product and less like an experiment.
Done doesn’t mean the prototype works. It means you have three things in writing: the answer to the question, the evidence for it, and a recommendation to go ahead, change the approach or stop. Stopping is a perfectly good result. It costs a week’s work, where finding the same thing out at the end of a full build costs the budget.
The evidence should be something you could show a sceptical colleague: what was tried, with what data, and what happened, including what failed. A supplier who says “it worked” without saying how hasn’t answered the question.
What to keep and what to throw away
Most of the code usually goes in the bin, and that’s healthy. It was written quickly to find something out, and it will contain shortcuts that you wouldn’t want underneath a real system, such as passwords typed into it or no handling for errors.
What you keep is the knowledge. That means the written answer, the list of things that turned out to be harder than expected, the sample data you used, the access you arranged and any constraints you found in other people’s systems. A prototype that ends with a better specification has done its job even if you never see its code again. If you do want to reuse some of the code, decide that on purpose, and have it reviewed before it carries anything real.
Four ways it goes wrong
The commonest trap is that the prototype becomes the product by accident. The demo works well enough, deadlines press and nobody ever scheduled the rebuild, so shortcuts end up carrying real work. Saying at the start that it’s disposable, and what would have to be true for any of it to survive, is cheap protection.
The demo is another weak spot. The pleasant screens get built while the awkward connection to the other system is faked, and the result looks finished having proved nothing. Whoever presents it should be able to say which part is real and which is pretend.
Tidy data causes quieter damage. Real records have gaps, odd spellings, duplicates and ten years of history. A test on twenty clean rows says little about forty thousand untidy ones, so a realistic sample does the job, as long as you’ve permission to use it and take care over personal data.
Then there’s the matter of who owns the question. Someone on your side has to supply the access and make the go, change or stop call, otherwise the answer arrives with nobody able to act on it and becomes a report that sits in a folder.
What to ask a supplier or consultant to deliver
Ask for the question to be written down before work starts, with the time limit, a rough cost ceiling and what you’d accept as an answer. At the end, ask for the answer, the evidence and the recommendation, plus what you’ve learned about the other systems involved. A prototype is a bounded piece of work with a clear end, so it’s a sensible point to bring in someone with the relevant technical experience if you can’t judge the answer yourself, and the written output is something to agree in the scope.
Judge it by whether you could make the decision. If you can, it was a good prototype, whatever it looks like. If you’d still need a second prototype to answer the same question, ask why. Be careful of a proposal whose first phase is the full build with a prototype label attached, and of an unwillingness to put “stop” on the list of possible outcomes.
An invented example
This is made up, to show the shape. A small wholesaler wants orders in its stock system to book couriers automatically instead of someone retyping each one into the courier’s website. The supplier’s quote covers the whole job. The owner asks first for a one-week test of a single question: can an order’s address, weight and service level be sent to the courier’s system without a person touching it, using the way in the courier offers?
The test uses a few hundred real past orders with customer details removed. It finds that ordinary parcels go through, but pallets need a field the stock system doesn’t hold, and about one address in twenty fails the courier’s checks. The written answer says to change course: build the parcel route, add the missing pallet field first and decide what happens to rejected addresses. The owner has a narrower job to price and knows where the risks sit. The idea itself looks sound, which nobody could say a week earlier.
If there’s one assumption behind your own idea that you can’t yet test, send us the question in a sentence or two and we can look at whether a short prototype would answer it.