Most prototypes fail before a single screen is drawn, because nobody wrote down the question they were supposed to answer. A prototype is not a small product. It is an instrument for reducing a specific uncertainty — and that distinction determines everything about how you build it.
Start with the question, not the screens
Write one sentence: "We are not sure whether ___."
Good versions:
- We are not sure whether warehouse staff will scan items if it adds a step.
- We are not sure whether customers understand what our pricing means.
- We are not sure whether the matching algorithm produces results people accept.
Bad versions — these are not questions, they're plans:
- We are not sure whether people will like the app.
- We are not sure whether the idea works.
If your sentence can't be answered by watching someone use something for fifteen minutes, it isn't a prototype question yet. Break it down further.
The four fidelity levels
| Level | Build time | Answers | Cost |
|---|---|---|---|
| Paper / sketch | hours | Does the concept make sense? | ~0 |
| Clickable | 2–5 days | Can people complete the flow? | €3K–10K |
| Functional | 2–4 weeks | Does the core mechanic actually work? | €15K–35K |
| Pilot | 4–6 weeks | Will people use it in real conditions? | €25K–50K |
The most common error is jumping to level three. Teams build a functional prototype to answer a question a clickable one would have settled in a week.
Paper
Sketches, printed screens, a whiteboard. Answers comprehension questions: does the person understand what this is and what they'd do next?
What you give up: anything about timing, delight or friction under real conditions. Paper flatters — everything feels fast when nothing loads.
Clickable
A linked design file. Answers flow questions: can someone get from intent to outcome without help?
This is where the highest ratio of insight to effort sits. Most product questions in the first month are flow questions.
What you give up: all questions involving real data, performance or edge cases. Every path is the happy path.
Functional
Real code, real logic in the one area you're testing, fake everything else. Answers mechanic questions: does the calculation, match, recommendation or sync actually produce something useful?
Keep the slice narrow. A functional prototype for a marketplace tests matching — not sign-up, not payments, not profiles.
Pilot
The narrow slice, in the hands of real users, in real conditions, for two to four weeks. Answers behaviour questions: will people change what they do?
This is the only level that produces evidence about adoption. It's also where you learn about the conditions nobody mentioned in interviews — bad network, gloves, noise, interruptions.
The mistake that makes prototypes worthless
Testing whether people like the idea instead of whether they'll change behaviour for it.
Liking is free. Everyone likes a well-designed thing being shown to them by its enthusiastic creator. Behaviour is expensive — it means abandoning a current workaround, learning something, or paying.
Practical fixes:
- Ask what they do today, in detail, before showing anything.
- Never explain the screen. If it needs narration, that's the finding.
- Ask for a commitment at the end — a pilot slot, a data export, an introduction to their manager. Enthusiasm that survives a request for commitment is signal; the rest is politeness.
A realistic six-week shape
Week 1 — question and current state. Write the uncertainty. Interview five to eight people about what they do now. Most prototypes get redirected here, which is the cheapest possible place to be redirected.
Week 2 — clickable, round one. Build the flow. Test with five people. Fix.
Week 3 — clickable, round two. Test the fixes with five different people. If round two still surfaces comprehension problems, do not proceed — the concept isn't settled.
Weeks 4–5 — functional slice. Build the one mechanic that carries the risk, against real data if the question needs it. This is where a working API slice matters; see API integration.
Week 6 — decide. Three outcomes only: build it, change it, stop. A prototype that ends in "let's do more research" usually means week 1 was skipped.
What to do with the code afterwards
Throw it away. Prototype code is optimised for answering a question fast: no error handling, no tests, no permissions model, no observability. Keeping it means carrying those omissions into a system people depend on.
What you keep is more valuable than the code: the data model that survived contact with real users, the flows that tested well, and a written list of the assumptions that turned out to be wrong.
From there, the numbers for building the real thing are in mobile app development cost, and the decision about where the team sits in nearshore vs offshore.
How we run it
We treat the prototype as a fixed-length engagement with a written question and a decision at the end — not an open-ended design phase. The build side is on our custom software page, and the shape of a full delivery in our programmatic directory case study.
If you have an idea and aren't sure which fidelity level answers your question, tell us the uncertainty — you'll get a written recommendation within 48 hours, including the case where the honest answer is "five interviews, no prototype."