What Does a Prototype Agency Actually Do?
The service boundary is genuinely unclear, and firms in four different businesses all use the same word. Here is what sits inside the job, what sits outside it, and how to tell them apart.
"Prototype agency" is one of the least standardised labels in UK software. Four firms in four different businesses all use it, and each means something different by it.
That is a practical problem, not a semantic one. If you commission the wrong kind of firm you get a deliverable that cannot answer your question, and you find out several thousand pounds later.
The short answer
A prototype agency builds a deliberately incomplete version of a product, quickly, so that real people can use it and you can find out whether the idea works: before the expensive decision gets made.
Everything else follows from that sentence. The speed is there because a slow answer is worth less. The incompleteness is there because completeness costs money and answers nothing extra. The real users are there because they are the only source of the information you are buying.
If a firm's process does not produce something a real person can use, it is doing a different job. It may be a good job. It is not this one.
What is inside the service
| In scope | What it means in practice |
|---|---|
| Working out the question | What decision is this meant to unblock, and what would change it |
| Cutting scope to fit | Deciding what is not built, which is most of the work |
| Building something usable | Real screens, real flows, real enough to hand someone |
| Getting it in front of users | Arranging, running and recording actual sessions |
| Reporting what happened | What people did, not what they said they liked |
| Telling you what it means | Including when the answer is that the idea has a problem |
What is outside it
Just as important, and where most disappointment comes from:
- Production engineering. A prototype is not built to scale, and should not be priced as though it were.
- Security, compliance and audit. Real products need them. A test of an idea does not, and adding them multiplies cost for no extra learning.
- Long-term maintenance. There is nothing to maintain; the artefact has a job and then it is done.
- Being the finished product. The most expensive mistake in this category is shipping the prototype to customers because it looked ready.
- Deciding for you. The output is evidence. The decision stays yours.
How it differs from the firms it gets confused with
| Firm type | What they optimise for | What you get | Where it falls short for testing an idea |
|---|---|---|---|
| Design studio | How it looks | Screens in Figma, often beautiful | Nobody can use it, so nobody learns whether they would |
| Development agency | A finished, production-ready product | The real thing, built properly | Months and tens of thousands before you learn anything |
| No-code builder | Speed and low cost | Something assembled from templates | Fine until the idea needs anything the template cannot do |
| Strategy consultancy | Analysis and recommendation | A document and a decision framework | The recommendation rests on opinion, not observed behaviour |
| Prototype agency | Learning, fast | Something real, tested, plus what happened | Not production-ready, and not meant to be |
None of these is wrong. They answer different questions. The mistake is buying one while expecting another: commissioning a design studio and being surprised there is nothing to test, or a development agency and being surprised it took four months.
There is a related trap in the mockup: a static design is not a prototype, however good it is. Prototype vs MVP vs wireframe sets out where each one sits.
What good practice actually looks like
"Best practice" in this field is not a methodology. It is four habits, and firms either have them or do not:
Build the riskiest thing first. The part of the idea most likely to be wrong should be the part that exists soonest. Agencies that build the easy screens first are managing their own delivery risk, not yours.
Keep fidelity as low as the question allows. Polish is expensive and it distorts testing. People comment on how something looks instead of whether it works. Enough realism to be usable, and no more.
Test with people who are not you. The team, the stakeholders and the investors are all the wrong audience. Why the distinction is not a technicality is worth reading before you agree a test plan.
Write down what was left out. The list of deliberate omissions is what makes the next phase quotable, and it is the first thing lost when nobody records it.
What a week actually looks like
Timescales vary, but a genuinely fast engagement compresses into days rather than months. A five-day shape looks like this:
| Day 1 | Agree the question, cut the scope, decide what is not being built |
| Days 2–3 | Build the version people will actually touch |
| Day 4 | Real users, real tasks, recorded |
| Day 5 | What happened, what it means, what to do next |
The compression is the point. An idea tested this week informs a decision you are making this month. The same test delivered in twelve weeks arrives after the decision was forced.
That shape is what a Prototype Sprint is: fully working, from £750, in five days. What a prototype costs in the UK sets that against the rest of the market, where a design agency mockup runs £5,000 to £15,000 and a full agency build runs £20,000 to £100,000 or more.
What you should have at the end
Six things. Ask for all of them before work starts:
- The working prototype, in a form you can show people yourself
- A record of what real users did with it
- A clear statement of what was learned, including anything unwelcome
- The list of what was deliberately not built
- A view on what to build next, and what to drop
- Ownership of everything above, in accounts that are yours
The sixth is the one to nail down early. It is covered in more detail in MVP development services, where the stakes are higher and the handover is bigger.
When you do not need one
Honestly: often.
- The idea is genuinely simple and cheap to build. Just build it.
- The decision is already made. If nothing the test could show would change it, you are buying reassurance, not evidence.
- The question is technical, not behavioural. "Will this integration work?" is a proof of concept, a different thing with a different shape.
- You have real usage data already. Then you have better evidence than a prototype would produce.
A firm that tells you this is a firm worth remembering next time.