How to Choose a Prototype Agency in the UK
You are being asked to judge work you cannot yet assess, from firms whose portfolios all look the same. Here is what actually distinguishes a good UK prototype agency from an average one.
Choosing a prototype agency is an unfair task. You are asked to compare firms whose portfolios all look equally polished, on work you have not done before, using a vocabulary the industry has not agreed on.
The polish is the problem. A portfolio shows you what a firm can make look finished. It tells you almost nothing about what you actually want to know: can they help you find something out?
This is about how to tell the difference. Which route to take (agency, freelancer, in-house or offshore) is a separate question, answered in how to hire an app developer in the UK.
What separates a good prototype agency from an average one
One thing, and it shows up everywhere once you know to look for it.
An average agency treats the prototype as the deliverable. A good one treats it as an instrument.
The average agency's incentive is to hand over something impressive. So the work drifts towards polish: pixel-perfect screens, a smooth demo, a case study photo. All of it optimised for how the thing looks in the meeting where it is presented.
A good agency's incentive is that you learn something you did not know. So the work drifts towards exposure: getting a rough version in front of real users early, deliberately testing the assumption most likely to be wrong, and being willing to tell you the idea has a problem.
Those two produce very different projects for similar money. And you can hear which one you are talking to within about ten minutes, because a good agency asks what you are trying to find out before it asks what you want built.
How to read a case study
Every case study says the project was a success. Four things reveal whether it was real work:
| Look for | Why it matters |
|---|---|
| What they learned | A case study with no finding is a portfolio piece, not a project |
| What changed | If the finished thing matches the first sketch, nobody tested anything |
| What was cut | Real scope decisions leave evidence. No cuts means no constraints |
| Who used it | "Tested with stakeholders" is not testing. Real users, named as such |
The strongest signal is a case study where something went wrong (an assumption failed, a feature was abandoned, a direction reversed) and the write-up says so. Agencies that publish those are describing work. Agencies whose every project went perfectly are describing marketing.
Bluprint's own are at case studies, and they are written that way deliberately.
Shortlisting: how many, and where from
Three is the right number. Two gives you no comparison; five gives you a spreadsheet and no judgement.
Get them from unlike sources, because each source is biased in its own direction:
- A directory: broad, but ranks by who invests in being listed
- A referral from someone who has actually commissioned this: the best signal available, and the hardest to get
- A firm whose written work you rate: someone whose articles or case studies told you something useful before you ever contacted them
Deliberately include one firm that is not the obvious fit. It is the cheapest way to find out whether your brief is right.
The two questions that tell you most
Ask both in the first conversation.
"What do you think is most likely to be wrong about this idea?"
You want a real answer. An agency that agrees your idea is excellent is selling. An agency that names a risk you had half-noticed yourself has read the brief and thought about it. This question is uncomfortable to ask and enormously informative.
"What would you build first, and what would you leave out?"
The answer reveals whether they think in terms of learning or delivery. "Everything you described" is a bad answer at any price. A short list with a reason attached is a good one, even if you disagree with the list.
What the proposal should tell you
Not the price. The price is the easy part to compare and the least informative.
Read it for assumptions. A serious proposal states what it is assuming about your users, your data, your integrations and your decision-making, because those assumptions are what the estimate rests on. A proposal with no stated assumptions has them anyway: you just cannot see them, and you will meet them later as change requests.
Read it also for what happens if the answer is no. Prototyping exists to make failure cheap and early. A proposal that has no shape for "we tested it and it did not work" has not understood the job.
The first fortnight is the real interview
However careful the selection, you learn more in two weeks of work than in any number of meetings. Agree a genuine checkpoint early, and judge these:
- Did something real appear quickly, or only documents?
- Did they tell you an uncomfortable thing without being asked?
- When you changed your mind, did the conversation get easier or harder?
- Are you looking at the product, or at a report about the product?
Structure the engagement so leaving after that checkpoint is possible and not catastrophic. An agency confident in its first two weeks will not object.
What this costs, so the comparison is fair
UK prices for "a prototype" cover an enormous range, because the word covers very different things:
| What you get | Typical UK cost |
|---|---|
| Design agency mockup: screens in Figma, not usable | £5,000 – £15,000 |
| Full agency build: the real product | £20,000 – £100,000+ |
| A Bluprint Prototype Sprint: fully working, testable | From £750, in 5 days |
The middle row is not a prototype and the top row often is not either: a static mockup cannot tell you whether people will use something, because nobody can use it. How much does a prototype cost in the UK breaks the range down properly.
When you compare quotes, make sure you are comparing what each one actually produces. "Prototype" on two proposals frequently means two different objects.
The bottom line
Judge a prototype agency on how it handles uncertainty, not on how its portfolio looks.
The firms worth hiring ask what you are trying to find out, name the assumption most likely to be wrong, get something real in front of real users quickly, and are willing to tell you the answer is no. That is a short list of behaviours, and it is visible in the first conversation if you ask for it.
Everything else (team size, tech stack, office, awards) is context. Useful, occasionally decisive, but never the thing that determines whether you end up knowing more than you did.