Nobody can tell you what they want from a description. Hand them the thing and watch.
We build a working, clickable version fast, put it in front of real people, and learn what they actually do, while changing your mind is still cheap.
Iterating
First draft, then feedback, then refined. The layout keeps moving because that is the point: changing it is supposed to be cheap.
The problem
The spec everyone signed off on is a list of guesses nobody has tested.
Requirements written in a document are predictions about what people will want and how they will behave. They feel solid because they are written down and everyone agreed, but until someone actually uses the thing, they are guesses. Confident, detailed, well-formatted guesses, and some of them are wrong.
You find out which ones the hard way: after the full build, when real users finally touch it and do something nobody planned for, ignore the feature everyone argued about for a week, and get stuck on the screen that seemed obvious. Now the wrong guesses are baked into a finished product, and fixing them means rebuilding, not rearranging.
A prototype moves that discovery to the front, while it is cheap. We build a version real enough to use but fast enough to throw away, put it in front of actual users, and watch where they fly through and where they stall. You change your mind based on what people do, not what they predicted in a meeting, and you do it before the expensive version is built around the wrong assumptions.
You have probably already lived this. A team builds a slick demo to win the room. The data is hardcoded, the search box only knows one query, and half the buttons go nowhere, but it looks finished. The stakeholder loves it, says "this is basically done, just wire it up," and a prototype that was meant to answer a question becomes a delivery deadline overnight. Six months later the same fakes are still in there, now load-bearing, and nobody remembers which parts were ever real. That is the trap. The prototype did its job perfectly and then got punished for looking too good.
The part nobody tells you
Fidelity is a dial. The whole skill is knowing where to set it.
Most people think a prototype is just a smaller, rougher version of the product. It is not. A prototype is built to answer one question, and how real it needs to be depends entirely on which question. A clickable mock with fake data answers a question about the flow: do people understand where they are and what to do next. A rough, ugly backend with no interface answers a different question: is the hard part even possible. Build the clickable mock to test feasibility and you learn nothing. Build the real backend to test a flow and you spent a month answering a question a sketch could have settled in an afternoon.
So you turn the dial deliberately, and you turn it as low as the question allows. The classic move is the Wizard of Oz: the user thinks the system is doing the work, but a person behind the curtain is faking it by hand. Don Norman and Allen Munro ran one of the first in 1973 with an automated travel assistant, and IBM used the same trick in the 1980s to test speech-to-text by having a typist in the next room transcribe in real time. No recognition engine existed yet. They were testing whether anyone actually wanted to dictate to a computer before spending years building the engine. The interface was the question. The engine was not, so they faked the engine.
This is also why polishing a prototype is more dangerous than it looks. There is real research on this: when the same idea is tested as a rough sketch and as a finished-looking mockup, people reviewing the rough version talk about the flow and what confused them, the feedback you actually need, while people reviewing the polished version critique the colors and the fonts and quietly assume the thinking is settled. A prototype that looks done gets treated as done, by your users and by your own stakeholders. The unfinished look is not laziness. It is an invitation to push back, and you want that invitation while changing your mind is still free.
Alberto Savoia, who coined pretotyping at Google, put the hard part plainly: building the fake thing is the fun part. The tough part is fighting your own urge to add one more feature and make it nicer before you let real people judge it. That urge is the enemy. Every hour you spend making a throwaway prettier is an hour buying confidence you have not earned yet, on code you are going to delete. The goal is not a beautiful prototype. The goal is the fastest honest answer, and then the courage to act on it.
How we run it
Real enough to learn from, cheap enough to throw away.
A prototype is a tool for learning, not a head start on the product. Treating it like the real build is how prototypes get slow and precious. These are the principles that keep it fast and honest.
Real enough to provoke a real reaction
People cannot react honestly to a wireframe or a description; they react to something that behaves. We build the prototype real enough that using it feels like the real thing, so the feedback is about how it actually works, not how someone imagines it might. The behaviour is the part worth testing, so we build the behaviour and fake the rest. In practice that means the parts a user touches respond like the finished product: the button does something, the next screen actually appears, the form complains when you leave it blank. The moment something behaves like a dead mockup, people stop reacting to your idea and start reacting to the fact that it is a mockup, and you have lost the test.
Fake everything that does not need to be real
Behind the convincing surface, almost nothing is. Data is mocked, the backend is faked, the hard engineering is stubbed out. We make real only what the user has to touch to give honest feedback, because every hour spent making the plumbing real is an hour not spent learning, on code we are going to delete anyway. The rule is simple: hardcode anything that does not change the answer. If you are testing whether people understand a dashboard, the numbers on it can be invented, the same numbers every time, because the layout is the question and the live data is not. Sometimes the fastest fake is a human: a person quietly doing by hand what the system will eventually automate, so you can test whether anyone wants the result before you build the machine that produces it.
Built to be changed, not defended
The whole point is to change it. So we build it loose and disposable, where rearranging a flow or trying a different idea takes an hour, not a sprint. A prototype you are reluctant to change has stopped being a prototype; it has quietly become the product, with all the wrong early assumptions still baked into it. The tell is emotional, not technical: the day you catch yourself defending a prototype instead of cutting it apart, it has stopped being a tool for learning and started being something you are protecting. We deliberately keep it cheap to gut, no migrations to fear, no abstractions to respect, so that throwing out a screen costs nothing and nobody hesitates to try the braver version.
Put it in front of real people
A prototype only the team sees teaches the team what the team already thought. The value comes from watching someone who was not in the room try to use it: where they hesitate, what they ignore, what they expected that is not there. We get it in front of real users and pay attention to what they do, not just what they say afterward. Words are polite and memory is unreliable; the hesitation before a click, the wrong button reached for, the feature scrolled straight past, those are the truth. We hand it over, say as little as possible, and resist the urge to explain, because the second you explain how it works you have hidden the exact confusion you came to find.
Match the fidelity to the question you are asking
Before we build anything we name the one question this prototype exists to answer, then make only the part that answers it real. A question about the experience needs a believable interface and can fake the engine entirely. A question about feasibility needs a rough working engine and barely needs an interface at all. Getting this wrong is the most common way prototypes waste a month: polishing pixels to answer a feasibility question, or hand-wiring a real backend to answer a question a clickable sketch would have settled by lunch. One prototype, one question, and the dial set exactly as low as that question allows.
Throw it away on purpose
When the prototype has done its job, we throw the code away and build the real thing properly, using what we learned. That sounds wasteful and is the opposite: the prototype bought you the right design cheaply, and shipping a throwaway that was never built to last is how you inherit a year of technical debt you chose on purpose. A prototype is built to be learned from, not kept. It cuts every corner on purpose: no error handling, no security, no tests, no scale, because those would slow down the learning and they are not what you are testing. Ship that as the product and every shortcut you took to move fast becomes a permanent liability someone else has to live with, usually without knowing it was ever a shortcut.
"A prototype is not a head start on the product. It is the cheapest way to find out you were about to build the wrong one."
What you get
What you actually learned, and the thing you learned it with.
A working prototype, real user reactions, and a clear read on what to build, and what to drop, before the expensive version starts.
- A working, clickable prototype real enough to put in front of real users
- The flows that matter made convincing, with the plumbing behind them faked
- Sessions with real users, and a record of what we watched them actually do
- A clear read on what worked, what confused people, and what nobody used
- Concrete changes to the plan based on behaviour, not opinion
- A recommendation on what to build for real, and what to cut
- The prototype itself, clearly labelled as a prototype so nobody ships it by accident
Got a spec everyone agreed on but nobody has tested? Let us build a version people can actually use, and find out what they really do with it.
Invoke usIs this the right call
When this fits.
Good fit
- You are about to build something on assumptions about what users want and how they will behave
- The team keeps arguing about a design decision a real user could settle in five minutes
- You need to show a working experience to users, a pilot customer, or stakeholders before the full build
- You want to test the experience and the flow, not whether the hard technical part is possible
Wrong call
- The uncertainty is technical, not about the experience. That is a proof of concept, and we should talk about that instead.
- The design is already validated and you just need it built well. Skip to building it.
- You intend to ship the prototype as the product. A prototype is built to be thrown away; tell us and we will build the real thing properly.
How it runs
Fast, disposable, and pointed at a decision.
A prototype runs in days, not months. We build the smallest convincing version that can teach us something, test it, and move, because the value is in the speed of the loop, not the polish of any one version. A prototype that takes as long as the product has missed the point entirely.
It iterates in public, with you. You see each version, react to it, and steer the next one, instead of waiting weeks for a reveal. Changing direction is expected and cheap; that is the whole reason to prototype instead of building straight away.
It ends with a decision and a clean slate. When we have learned what we needed, the prototype has done its job. The real build starts fresh, properly engineered, using the validated design, instead of trying to grow a throwaway into production and dragging its shortcuts along forever.
What we settle before we begin: the specific question about the experience we are trying to answer, who needs to use the prototype for the feedback to count, and that everyone agrees it gets thrown away. Everything else follows from those three.
Tell us what you are about to build on a guess.
Describe the product or the flow, and the assumptions about how people will use it that nobody has tested yet. We will build a version they can actually try, and tell you what they do with it, before you commit to the real thing.