What a working prototype is
Unlike a mockup or a clickable picture, a working prototype functions: real data, real input, a task finished end to end, rough edges and all.
We build five kinds:
- Interaction prototypes test how something feels to use.
- Concept prototypes show whether an idea is worth pursuing.
- Data prototypes show the product with your real information.
- AI prototypes test whether a model does the job reliably enough to build on. One we built for a media company interviews an advertiser and turns the conversation into a draft sponsored article for a person to approve.
- Technical prototypes prove a risky piece of engineering works before the rest is built around it.
Why prototypes, and why now
Modern frameworks and AI-assisted development have cut a working prototype from months to weeks.
When building the wrong thing was ruinous, teams settled everything on paper. Now a rough version is usually cheaper than a debate, so prototyping moves to the start of the project, where it does the most good.
A deck asks people to imagine; a prototype lets them react. They spot problems (and opportunities) they’d never see in a description, and clients often get more ambitious once something works.
Disposable on purpose
Some prototypes answer one question or settle one decision, then get thrown away. That’s what makes them fast: no over-engineering, no early polish, no handling every case.
Others grow into real products, which means rebuilding or hardening them for security, reliability and structure. We’ll tell you which kind you need, and won’t gold-plate one that should stay rough.
Climbing the ladder
Good projects often climb three rungs:
- Prototype. Built fast to answer a question or prove an idea. Often thrown away; sometimes hardened into a product.
- Tool. Works for a small, known group. Sometimes that’s the end state; sometimes it shows what production needs.
- Production. Hardened software for people who depend on it, built on what the earlier rungs taught us.
Investment follows evidence, so nothing large rests on an untested assumption.
What we prototype first
The riskiest, most uncertain part. The rest can wait.
- If the value hinges on one interaction, we build it.
- If it hinges on a model doing a task reliably, we test the model on that task.
- If it hinges on usable data, we connect the data.
For creative work like a 3D homepage or an interactive map, we build rough interactive versions early and work through them with the client, to agree on what feels right before detailed modelling and design.
Testing with real people
We put prototypes in front of the people who’ll use them, beyond the project team, and watch where they hesitate and what they ignore. Then we change it and test again; a few short rounds usually teach more than weeks of planning.
Testing tells you which version works better. It can’t tell you whether a better idea exists, so prototyping sits alongside discovery.
From question to prototype
- Define the question the prototype needs to answer.
- Build the smallest thing that answers it, usually on the stack we’d use in production (currently Next.js and Supabase), so a prototype that earns its way forward can be hardened instead of rebuilt.
- Test it with the people who’ll use it, in short rounds.
- Document what we learn, so decisions stay traceable when the product moves on.
