Services / Design / Prototypes

Try the product before you build it, in days, not months

A prototype is the cheapest place to be wrong. It looks and behaves like the real thing, your customers can use it on their own device, and changing your mind about it costs an afternoon instead of a sprint.

Start the conversation →See the technology

Why it matters

The cost is the wait

The most expensive way to discover that a feature is wrong is to build it. By then the decision is baked into a database schema, an API contract, a test suite and six weeks of somebody's calendar, and the sunk cost makes everyone reluctant to say so out loud. A prototype moves that discovery forward to the point where being wrong is nearly free.

This is not a wireframe or an animated slide deck. It is a version of the product people can click through unaided, with realistic content, real flows, and the states that make software confusing: errors, empty screens, waiting. Put it in front of a few actual customers with a task to complete and you learn more in an afternoon than in a month of internal debate.

We build them fast and deliberately disposable. Depending on what you need to prove, that is an interactive design file, a coded front end running on realistic data, or a rough working slice. Whichever answers the question you actually have. Then we tell you what the sessions showed, including the times the answer is that the idea needs rethinking.

What you actually get

Built to be trusted

A prototype is only worth building if it answers a specific question. These are the things we build in to make sure it does.

Realistic content, not placeholder text

Lorem ipsum hides the problems that real names, long product titles, empty fields and awkward numbers expose immediately. We prototype with content shaped like yours, because that is where layouts and labels break.

The unhappy paths included

Errors, timeouts, empty states, a rejected form, a permission denied. Testing only the route where everything goes right tells you nothing about the moments that actually make people give up and close the tab.

Fidelity chosen on purpose

Rough grey boxes when the question is about structure; a polished, near-real build when the question is about desirability or when you are showing an investor. Higher fidelity is not automatically better, it draws comments about the colour instead of the concept.

It runs on a device, not a projector

Shared as a link people open on their own phone or laptop, so they use it the way they would use software, rather than watching someone else drive and nodding along politely.

A test plan, not just a demo

Specific tasks, a script and a way of recording what happens. "What do you think?" produces politeness; "buy this item and change the delivery address" produces evidence you can act on.

A decision at the end

Findings written up as what worked, where people stalled, what to change and what to drop, with clips of the moments that matter. The output of a prototype is a decision, not a deliverable to admire.

Where it earns its keep

Same pattern, different desks

Prototypes earn their keep in three situations: before a build, before a raise, and before a large internal argument.

01 · Startups & new products

Proving there is something there before the build budget goes

The problem: You have a strong idea and a quote for building it that represents most of the money you have. Nobody outside the founding team has ever used it, and the entire plan rests on the assumption that they will understand it as quickly as you do.
What we build: A clickable version of the core flow within days, tested with people who genuinely fit the target customer, followed by a scoping session that turns what we saw into a build plan with the unnecessary parts removed.
What changes: A decision made on evidence rather than conviction, and a build brief for a smaller, sharper first version than the one originally quoted.

02 · Manufacturing & enterprise operations

Getting internal agreement without building three versions

The problem: Four departments each hold a different picture of how the new internal system should work. A requirements document keeps that disagreement hidden until the software arrives and nobody is happy, which is the most expensive possible moment to find out.
What we build: A prototype of the contested workflows, walked through with each department in turn and revised between sessions, so the arguments happen against something concrete and get settled in days rather than in a change request later.
What changes: A specification everybody has actually used and signed off, and a build that starts with the disagreements already resolved.

03 · Marketplaces & consumer apps

Testing the moments the business model depends on

The problem: The model rests on people completing something they have never seen: listing an item, accepting a booking, paying a deposit, trusting a stranger. Building both sides of it takes months, and every assumption underneath is currently untested.
What we build: A prototype of both sides of the transaction with realistic listings, prices and profiles, put in front of recruited participants from each side, with tasks aimed squarely at the moments carrying the most risk.
What changes: Evidence about the riskiest assumptions gathered before the platform is commissioned, and a prioritised list of what to change first.

The technology

The tools behind it, named

What we prototype in depends on the question. A design-file prototype answers "is this understandable"; a coded one answers "does this hold up with real data".

6 layers · 21 technologies

Clickable prototypes

Interactive without a build. Good enough that people forget they are testing something, fast enough to change between sessions.

Figma
Framer
ProtoPie

Coded throwaway prototypes

When the question needs real data, real search results or a real integration, we build a front end quickly and expect to delete it.

Next.js
React
TypeScript
Tailwind CSS
shadcn/ui

Motion & feel

Where the thing being tested is responsiveness or delight, the prototype has to move properly. Static screens cannot answer that question.

Rive
Lottie
Adobe After Effects

Workshops & mapping

The hour or two before anything is built, where the flow gets agreed and half the ideas get cut.

Miro
Notion
Loom

Running the sessions

Recruiting participants, setting tasks, recording what happens, and keeping the evidence somewhere your team can watch it.

Maze
Dovetail
Hotjar
UserTesting

Sharing & hosting

A link that opens instantly on any device, password-protected where the idea is sensitive, and switched off when the round is over.

Vercel
Cloudflare
Webflow

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Most prototype rounds take one to three weeks end to end, including recruiting, the sessions themselves and the write-up.

We write down the question

One or two sentences: what decision does this prototype have to unblock. Without that, prototypes drift into a general demo that proves nothing and takes three times as long to build.

We sketch the flow

The path a person takes through the thing being tested, agreed on a whiteboard in an hour or two. Anything outside that path is deliberately left as a dead end so we do not draw screens twice.

We build it, fast

Interactive within days, using realistic content and covering the states that matter. Fidelity is set by the question, and we resist polishing the parts nobody in the session will ever look at.

We recruit and run the sessions

Participants who genuinely resemble your users, given specific tasks, recorded with permission. We watch what they do rather than asking what they think, the two answers rarely match.

We tell you what we saw

A short report: what worked, where people stalled, what to change, with the clips that make it undeniable. Including, when it happens, the finding that the concept needs rethinking. That is precisely what you paid for.

We turn it into a build plan or another round

Either a scoped brief for the real build, with the tested flows serving as the specification, or a second prototype round on the parts that failed. Both are considerably cheaper than finding out after launch.

Before you commit

The questions worth asking

Could we skip this and just build the real thing?

Sometimes, yes. If the flow is a well-understood pattern your team has shipped before, prototyping it is ceremony. The prototype earns its cost when the risk sits in whether people will understand or want the thing: a new concept, an unfamiliar audience, a contested internal workflow. And when the risk is purely technical rather than human, a technical spike is the better spend, and we will tell you that instead of selling you a prototype.

Can we reuse the prototype as the actual product?

For design-file prototypes, no. There is no code in them. For coded prototypes there is code, but it was written to be fast rather than to be maintained: no tests, no error handling, no security review, no thought given to what happens under load. Teams that carry a prototype into production inherit a codebase they cannot change safely, and pay for it for years. We build prototypes to be thrown away, and we say so at the start so nobody plans otherwise.

How many people do we need to test with?

Fewer than most people expect. A handful of well-chosen participants surfaces most of the usability problems in a given flow, because the serious ones are hit by nearly everybody. Large numbers matter when you are measuring preference or conversion rates, not when you are finding out where people get stuck. What matters far more than the count is that the participants actually resemble your users.

Our users are hard to reach: specialists, clinicians, senior buyers.

That is common and it genuinely changes the cost and the timeline, so we plan for it rather than pretending otherwise. Options include recruiting a smaller number of real participants with a meaningful incentive, running sessions remotely in short slots that fit a working day, testing with your own client-facing staff as an imperfect proxy, or piggybacking on meetings that are already in the diary. We will be clear about what each option can and cannot tell you.

Will a prototype tell us whether people will pay?

Not reliably. Stated intention and actual payment are different things, and a prototype only measures the first. People are consistently more enthusiastic in a session than they are with a card in their hand. What a prototype does establish is whether people understand the offer, whether the flow makes sense, and where they hesitate. Pricing needs a real transaction, or at least a real commitment, to test properly.

What do we get at the end?

The prototype itself as a shareable link, the session recordings and clips, a written findings report with recommendations ordered by impact, and an updated flow reflecting what we learned. Where the next step is a build, we can also provide a scoped brief your developers or ours can quote against.

What are you about to build on an assumption?

Tell us the one thing your plan depends on that nobody has tested yet. We will tell you whether a prototype could settle it and roughly what that would take: free, no strings.

Start the conversation →

Explore more

The rest of Product & Brand Design

Product design Brand identity Design refresh ← All of Design