Contents6
The cheapest moment to change an app is before it exists. A clickable prototype lets people try it without building it: screens linked together, tapped or clicked through like the real thing. Before any development, it shows whether future users find their way, and it turns a vague idea into a scope a quote can price.
In short
A clickable prototype simulates the app: you navigate, nothing is saved.
Five testers of the same profile are enough to see most of the blockers, and several small tests beat one big one.
The test does not ask “do you like it?”; it gives tasks and watches where people hesitate.
The approved prototype becomes the basis of scoping: what is in it gets priced, the rest will wait.
What a clickable prototype is, and what it is not
Definition
Clickable prototype
A series of designed screens linked together: tapping a button leads to the next screen. It shows the app’s journey and look, with no database or rules behind it.
It differs from two things it is often confused with:
- A screen image is looked at; a clickable prototype is gone through. It is the journey that is tested, not the colour of the buttons.
- A coded prototype really works, with data. It costs more, and it is often hard to throw away when it should be.
Interface design tools (Figma, or Penpot on the open-source side) produce this kind of prototype, and AI interface generators draw a first version in a few minutes. The tool matters little: what matters is putting it in the hands of the right people.
Why test before coding
Changing a screen in a prototype takes minutes. Changing a journey in a developed app means reworking screens, rules, tests, sometimes the database. Testing on a prototype is about making mistakes where they cost least.
It does not need to be big. The most quoted argument comes from Jakob Nielsen, of the Nielsen Norman Group:
per test, the size he recommends
of usability problems found by a first study with five participants, according to his model
of five people rather than a single one of fifteen, for the same budget
It is a rule of thumb, not a law: the article dates from 2000, and its author himself says you need to test more users when they form highly distinct groups (a field technician and an office assistant will not stumble on the same screens). But the idea holds: several small tests, with a fix between each, teach more than one big one.
How a prototype test runs
- Pick three real tasks.
“Mark a job as done”, “find a client’s file”: everyday actions, not a guided tour.
- Recruit real users.
Five people from the target profile, not project members, who already know the answer.
- Let them do it, without helping.
Ask them to think aloud; note where they hesitate, go back or look for a button that does not exist.
- Fix the prototype.
Blockers seen by several testers come first.
- Test again.
With other people, on the corrected version.
Watch out
The question “do you like it?” is useless
Out of politeness, most testers say yes. What counts is what they do: is the task completed, in how long, with what hesitations.
What the prototype settles for what follows
An approved prototype is not just a drawing: it is the best possible description of what the app must do on day one. Each screen says what to display, each button what to save, each journey who is allowed to do what.
It is what makes a line-by-line quote possible rather than a range. The decisions that drive the price (accounts and roles, real time, offline, notifications, integrations) appear in black and white, as we explain in what drives the price of an app. And what is not in the prototype waits for a later version: the best protection against features added along the way.
Key takeaway
The prototype serves twice: it gets the journey tested by real users, then it becomes the written scope that development must hold to.
When can you skip it?
The prototype is not a mandatory step. You can skip it, or reduce it to a few screens, when:
- The app follows a journey the team already knows by heart, for example an existing paper form to put on a phone.
- A first version can be live very quickly. For Challenge Us, a group-challenge app we built, the idea, the scoping and the first code fit into the day of 1 September 2026, and version 1.0 was running in the browser the next day. In that case, a real installable version, in the hands of users, plays the prototype’s role: the approach described in our comparison of installable web apps and store apps.
- The decision is not about the journey but about choosing between existing software and development: see custom-built or off-the-shelf.
A prototype generated in minutes by an AI is tempting, but it has the limits of any prototype: it shows a journey, not a product that holds up in production. We discuss this in our article on vibe coding.
To go from an approved prototype to an app in service, our app development starts with this written scoping, then puts a first version in your users’ hands.
Frequently asked questions
How long does it take to make a clickable prototype?
It depends on the number of journeys and user profiles: you need to design the main screens, run one or two rounds of tests with five people, and fix things in between. For an app with a few journeys, it is a matter of days rather than months. Each very different profile needs its own testers, so a little more time.
What is the difference between a clickable prototype and an MVP?
The prototype simulates: you navigate, but nothing is saved, and it can be thrown away without regret. The MVP, the minimum first version of the product, really works, with data and accounts. The prototype validates the journey before coding; the MVP validates real use once coded. The two often follow each other in that order.
Should a prototype be tested with external users?
With the people who will actually use the app, whether customers or employees. Project members are not suitable: they already know the way. For an internal app, five colleagues from the relevant job are enough; for an app aimed at your customers, a few real customers, recruited for half an hour each.
Is a prototype made by an AI enough?
It is enough to start the discussion: an AI quickly produces a first set of screens. But it proposes the most expected journey, not necessarily yours, and it has not been tested. A prototype’s value comes from testing with real users and the fixes that follow, whatever tool drew it.
Jim · founder of Brain Plus AI
Also in web and mobile apps
Choose and price6 min
Business app: custom-built or off-the-shelf software?
Off-the-shelf software costs less as long as your way of working fits its boxes. Here are the signs that tip the balance towards custom, and the middle path that is often forgotten.
Choose and price6 min
How much an app costs: what makes the price vary
A price range says nothing about your project: what makes an app quote vary is a handful of specific decisions, plus a monthly running cost to be priced separately. Here they are.
Choose and price6 min
PWA or native app: which to choose for your business?
An installable web app (PWA) goes onto the home screen without going through the App Store or Google Play, and is enough in many cases, not all. Here is how to decide, and why we start with it.