What Does an App Prototype Cost?

Fidelity levels and their cost

Fidelity	What it looks like	Good for	Relative cost
Sketch	Hand-drawn or boxy screens, no styling	Agreeing the flow with a co-founder in a day	Lowest; often done in-house
Wireframe	Grey boxes, real labels, clickable	Testing whether users understand the flow	Low
High fidelity	Final colours, typography, icons, motion	Testing trust and appeal, pitching, briefing developers	Highest; most of the design hours

Most founders need wireframe fidelity for the whole core flow and high fidelity for three or four key screens. Paying for every screen at high fidelity before testing is the most common waste.

Number of flows and screens

A flow is a path through the app that ends in something: sign up, book, pay, check status. Each flow is typically five to twelve screens including the error and empty states nobody thinks of at first. The price scales with flows more than with screens, because each flow is a design problem of its own, while extra screens inside a flow are mostly variations.

One core flow: the reason the app exists. Always in the prototype.
Onboarding and login: needed if you test with strangers, skippable if you test with friendly users.
Settings, profile, history: usually left as static screens or omitted.
Admin or provider side of a two-sided app: a second prototype in practice, and priced as one.

State the flows you want before asking for a price. 'A prototype of the app' is unpriceable; 'a prototype of booking and paying, plus a login screen' is a fixed job.

Testing included or not

A prototype without a test is a picture. The value comes from putting it in front of five people who resemble your users, giving them a task, and watching where they hesitate. Some quotes include that round; many do not, and the difference matters more than the design hours. Ask specifically: how many test sessions, who recruits the participants, and whether the findings come back as a list of changes or as a video you have to interpret.

Included

Five short sessions, a findings list ranked by severity, and one revision round of the prototype. This is what you want.

Not included

Design only. Fine if you will run the tests yourself, which you can with a free recording tool and a clear task.

Over-included

Large panels, formal reports, statistics on five people. Costs more and tells you less than watching the sessions.

Using the prototype to get quotes

This is the underrated use. Send the same prototype to three developers and their quotes become comparable, because they are all pricing the same screens and the same flows instead of their own interpretation of a paragraph. It also exposes scope: a developer who asks 'what happens when the payment fails?' has found a screen the prototype lacks, and you can add it for an hour of design rather than discover it mid-build.

Export the prototype link and a screen list with a one-line purpose per screen.
Add a short note on integrations: payments, BankID, maps, notifications, an existing backend.
Ask every developer for a fixed price per flow and a list of what is out of scope.
Compare the out-of-scope lists first. That is where the quotes actually differ.

When to skip straight to build

We sell prototypes, and still: some apps do not need one. If the app is a mobile front end on an existing web product with proven flows, copy the web flows and build. If it is an internal tool for ten staff who will be trained anyway, a wireframe sketch in an afternoon is enough. If the developer you have chosen works in short cycles with weekly demos, the first cycle is effectively a prototype in code, and you can skip the separate step. In those cases the money is better spent on the build, or on our restaurant app cost check style question: whether an app is needed at all.

When the flows are genuinely uncertain, when strangers will need to understand the app without training, or when you are about to spend a build budget on an unverified idea, the prototype is the cheapest insurance you can buy. The pricing page has the fixed price, and a short call will tell you which of the two situations you are in.

Frequently asked questions

Can I use the prototype to raise money or pitch partners?

Yes, and it is one of the best uses of a high-fidelity version: a clickable prototype on a phone communicates an idea faster than any slide. Keep it honest with the audience, though; a prototype demonstrates the experience, not that the technology behind it works.

Is a prototype the same as an MVP?

No. A prototype has no code and saves nothing; it exists to test understanding and appeal. An MVP is a working product that real users can use and pay for. The prototype comes first and is typically a small fraction of the MVP's cost.

Who owns the design files?

You should. Ask for the Figma file to be transferred to your own account at the end, with all components and assets, so that any developer or designer can continue from it. A prototype that lives only in the agency's account is a dependency you did not need.

Can I build the prototype myself?

For a sketch or a simple wireframe, yes; Figma and similar tools have free tiers and templates, and a founder who knows the flows can produce something testable in a few evenings. Buy help when the flows are complex, when the prototype must look final for a pitch, or when you want an outside eye on the UX before the build.