The importance of prototyping comes down to timing. It is the cheapest moment in a software project to discover that you and your supplier mean different things by the same words. A prototype puts something people can see and click in front of them before the expensive work begins, so a misunderstanding surfaces within days and takes hours to put right. The same misunderstanding found after the system has been built takes weeks, and somebody has to pay for them.
This article is for the person commissioning a business system. It covers what prototyping should settle, what it cannot tell you, how much is enough and what to ask a supplier.
The kinds of prototype
“Prototype” is used loosely, and it helps to know which kind is on offer.
- A screen prototype shows the screens and the route through them, on paper or as a clickable mock-up. It tests whether the system matches the way the work is done.
- A working prototype runs on a sample of your own data, such as the spreadsheet the process lives in today. AI-assisted development has made these quick enough to build that they can be used to investigate a project before its price is set.
- A technical prototype, sometimes called a proof of concept or a spike, has little or nothing to look at. It answers one risky technical question: for example whether the data can be extracted from the old system, or whether the accounts package will accept orders from outside.
A project may need one of these or all of them. The vocabulary of wireframes and mock-ups is explained in our article on the differences between a wireframe, a mock-up and a prototype.
What prototyping settles before the build
Requirements that people can check. Few people can read a long written specification and say with confidence that it is right. Almost anyone can look at a screen and say “that is not how we handle returns”. The people who do the job react to a prototype with corrections that no document would have drawn out of them.
The exceptions. Every business has rules it takes for granted: the customer with two delivery addresses, the order that is part-shipped, the approval that is skipped below a certain value. They rarely appear in a brief. They appear the moment somebody tries to do a real task on a prototype and finds no way to do it.
A price that rests on something. A fixed price depends on a scope both sides understand. A supplier who prices from an agreed prototype is pricing something that has been seen and tested, and has less need to pad the figure against the unknown. This is a large part of how fixed-price development is made dependable.
What to leave out. Seeing the whole system laid out makes it far easier to decide what the first version does not need. Features that sounded essential in a meeting often look optional on a screen.
Technical risk. If the project depends on connecting to another system or on moving old data, a technical prototype finds out early whether that is straightforward. If it is not, you learn it while changing the plan is still cheap.
Agreement about “finished”. A prototype that has been agreed becomes a reference for the build, alongside written acceptance criteria. Arguments at the end of a project about whether something was included are much rarer when both sides can point at what was signed off.
Support from the people who will use it. Staff who helped to shape a system during prototyping are more likely to welcome it at launch than staff who meet it for the first time in a training session.
What a prototype cannot tell you
A prototype is persuasive, and that is its main danger. It looks like software, so people conclude that the real thing is nearly done. It is worth being clear about what has not yet been shown.
- That it will cope with real volumes. Fifty sample records say nothing about how the system behaves with five years of history.
- That the data will move across cleanly. Old data is nearly always messier than expected, and a screen prototype does not touch it.
- That it is secure. Permissions, audit trails and protection against misuse are built later and take real time.
- That it handles failure. Prototypes follow the path where everything goes right. A production system has to deal with lost connections, duplicate submissions and half-completed work.
This matters more now that a convincing prototype can be produced very quickly. The speed is real and useful, but it applies to the visible part. The work beneath it still has to be done.
A related question is what happens to the prototype afterwards. Some are thrown away once they have done their job. Others are built to become the foundation of the real system. Either is reasonable if it is decided on purpose. What goes wrong is a throwaway prototype being quietly promoted into production because it already exists.
How much prototyping is enough
Prototyping should be in proportion to the project.
For a small internal tool, two or three rounds over a week or two are usually enough: show it, collect corrections, change it, show it again. For a larger system, do not try to prototype every screen. Choose the tasks that are done most often and the ones that carry the most risk, and leave the routine screens to the build.
Three habits keep it productive:
- Involve the people who do the work, not only their managers. Include one person with the authority to decide when opinions differ.
- Keep it rough until the steps are settled. A polished prototype attracts comments about colours and wording. A plain one keeps attention on whether the process is right.
- Set a limit. Agree the number of rounds or the time allowed. You have done enough when a round produces only small changes that do not affect the size of the project.
If you would like to arrive at a supplier with your own ideas already tested, our guide on how to prototype an app without design skills shows how to do a first version yourself.
What to ask a supplier about prototyping
These questions sit well beside our wider list of questions to ask a software supplier.
- Will you prototype before the price is fixed, and is that stage priced separately?
- Which tasks will the prototype cover, and which will it leave out?
- Is there a technical question you would test first, and how?
- Will the prototype be thrown away or built upon?
- Who do you need from our side, and for how many hours?
- If the prototype changes the scope, how does that reach the price?
- Is the prototype ours to keep if we go no further with you?
A supplier who intends to go straight from a written brief to a fixed quotation for a system of any size is either adding a large allowance for risk or has not yet found the difficult parts. Ask which it is.