Why we build clickable prototypes before writing production code
A working prototype answers questions a specification never will. Here is how we use clickable prototypes to align teams, test journeys and scope projects before writing production code.
Key takeaways
- Prototypes turn opinions into decisions: everyone reacts to the same working screens
- Show every role together, customer, provider and admin, to expose gaps in the journey
- Use realistic local details, such as currency, payment methods and language, from day one
- A tested prototype makes estimates, timelines and the first release far more accurate
Specifications describe what people think they want. Prototypes show them what they will actually get. Before we write production code for a new product, we often build a clickable prototype: a working version in the browser, with realistic screens and sample data, that everyone can try. You can try several of ours on our Work page.
Why prototypes change the conversation
When stakeholders review a document, each imagines a different product. When they click through the same prototype, the discussion becomes concrete: this button, this step, this rule. Decisions that would take weeks of meetings are settled in an afternoon.
Show every role at once
Most products serve several groups of people. A home services platform has customers, service providers and administrators; a hospital system has front desk, nurses, doctors, lab and pharmacy. Problems hide in the hand-offs between roles. That is why our prototypes often show all roles together. In the HomeServ prototype, the customer app, provider app and admin panel run side by side: book a service in one and watch the others update. The hospital and clinic management prototype follows one patient from registration to pharmacy across every department.
Make it local from day one
Realistic details expose real requirements. The Lewach Market prototype for Addis Ababa runs in English and Amharic with local payment methods; HomeServ is set up for Liberia with Orange Money and MTN MoMo. Seeing the right currency, language and payment options early surfaces questions about pricing, translation and integrations long before development starts.
What a prototype is not
A prototype is not the product. It has no production backend, security model or integrations, and we label it clearly as a demo. Its job is to answer questions about the experience and the scope, so that design and engineering can start from decisions instead of assumptions.
From prototype to release
- Discover: agree goals, users and constraints.
- Prototype: build the key journeys for every role.
- Test: walk through it with stakeholders and real users.
- Scope: turn decisions into a release plan and estimate.
- Build: design and engineer the production product, often starting from one of our ready-built solutions.
Our product strategy and discovery and UX and UI design teams run this process. If you have an idea you want to test, ask us for a prototype.
Put this guide into practice
Frequently asked questions
What is a clickable prototype?
An interactive version of the product that people can click through in a browser, with realistic screens and sample data, but without a production backend.
How long does a prototype take?
Usually days to a few weeks, depending on the number of roles and journeys.
Do prototypes replace design and development?
No. They de-risk them: decisions made on the prototype carry into design and development with far fewer surprises.
Can we test a prototype with users?
Yes. Prototypes are ideal for user testing, investor demos and internal sign-off before committing a full budget.
