Guide · for product managers and designers deciding how real the prototype has to be
Mobile app prototyping in 2026: three fidelities, and when the prototype should already be the app
A mobile app prototype exists to answer a question before the app exists. There are three fidelities to answer it with — a click-through in Figma, a working web prototype, and a native build — and each answers a different question at a different cost of throwing it away. This page says what each one proves, when each one is enough, and the case that changed in 2026: when the same PRD that would have produced a prototype can produce the native v1 instead, so that nothing is thrown away.
Verified
The short answer. Prototype at the lowest fidelity that answers the question you have. Is the flow understandable? — a click-through in Figma. Does the thing work, with real data and real states? — a web prototype (Lovable, v0, Bolt, Figma Make). Does it feel like an app on a phone, and will people use it on day three? — a native build, which is the point where in 2026 the prototype and the v1 become the same object. The sequencing mistake is not choosing the wrong fidelity; it is building the second fidelity when the first would have answered the question, or building the second when the third was going to be needed anyway.
Two words that this page uses precisely. A prototype is built to be thrown away once it has answered its question. An MVP — the smallest version real users use — is built to be kept. The web tools blur the line by making prototypes that look like products; the native route blurs it from the other side by making v1s as fast as prototypes used to be. Knowing which you are building decides the fidelity.
Fidelity 1 — the click-through: does the flow make sense?
A Figma prototype: frames wired with hotspots, played on a phone. It costs a designer’s afternoon and throws away nothing, because the frames are the design work anyway.
What it answers: whether the flow is understandable, whether the navigation model is right, whether the screens are in the right order, whether a stakeholder can picture the product. What it cannot answer: anything with data, states or timing — there is no empty state that fills, no error that appears, no list that scrolls with real content, and nothing the user can do that you did not wire.
When it is enough: early discovery; a roadmap conversation; a usability test of a single flow with five people from the target group, where the task is “show me how you would book a session” and the finding is where they hesitate. Most product teams stop here too late, not too early.
Fidelity 2 — the web prototype: does it work?
A working web app from a description, a PRD or the Figma file: Lovable, v0, Bolt, Figma Make. Lovable’s prototypes page states the job in its H1 — “Proof of concept in hours, not weeks” — and its steps: “Turn tickets, docs, and wireframes into working prototypes”, “Make your PRD real”, “Skip the eng backlog”. Its product-managers page describes the loop: start with a question, build a realistic prototype, test and align, “Roadmap with confidence”.
What it answers: whether the logic works with real data; what the empty, loading and error states are; how complex the feature really is (“to evaluate complexity and edge cases without pulling favors from engineering”, in Lovable’s words); what the stakeholder objections are once there is something concrete to object to. What it cannot answer: how the product feels in a hand on a phone — push notifications, offline, camera, widgets, the store — because it is a web page in a browser; Lovable’s FAQ states it “does not generate React Native projects” and names a PWA or a Capacitor wrapper as the routes to a phone. And the last H2 on the same page is the cost of this fidelity: “Handoff to dev”. The prototype is thrown away; the FAQ asks it directly: “How do prototypes become production code?”
When it is enough: the product is a web product; the question is about logic, data or complexity; the decision is whether to build at all, and a throwaway is the cheapest way to find out. This is a large share of PM prototyping, and the web tools are the right choice for it.
Fidelity 3 — the native build: does it feel like an app, and will people keep using it?
Real Swift/SwiftUI on iPhone, Kotlin/Jetpack Compose on Android, installed from TestFlight or an internal track, used for a week. Until 2026 this fidelity was engineering time, which is why product teams prototyped at fidelity two and handed off. The change is that an agent now writes the native code from the same inputs the web tools take.
What it answers: the questions only a phone can answer. Does the app earn a place on the home screen? Do people open it on day three? Is the one-handed use right? Do notifications land at the right moment? Does it survive a tunnel? These are the questions the second fidelity leaves open, and for a mobile product they are the questions.
What it costs: a description that is actually a spec. In Modaal the first prompt takes “text, images, Figma links — whatever you provide”, including a PRD “with no text at all”; with Plan on the agent produces “a structured implementation plan (a feature spec) without writing code”, and the build starts when you approve it. The native build is not as fast as a click-through, and this page does not claim it is; it is as fast as a web prototype for a team that already has the PRD, and unlike the web prototype it is not thrown away.
When it is enough — and when it is the right first step: the product is an app; the question is retention, feel or a phone capability; and the v1 is going to be native anyway. In that case the “prototype” is the v1 with the scope of section 4 of the PRD, and every week spent at fidelity two is a week of handoff added later. Vibe coding for product managers is the argument in full.
The decision: which fidelity, from the question you have
Write the question first. Not “build a prototype” — “find out whether X”. The fidelity follows from X.
If X is about understanding (flow, order, navigation, whether stakeholders picture it): fidelity one. Test with five people from the target group; a click-through and a task are enough.
If X is about working (logic, data, states, complexity, whether to build at all) and the product is web, or the mobile decision is not made: fidelity two. Keep it a throwaway on purpose; write the handoff into the plan from the start.
If X is about the phone (feel, retention, notifications, offline, the store) or the v1 is going to be native regardless: fidelity three, scoped to the PRD’s v1. The prototype is the app; the test is TestFlight with real users for a week.
If X is about whether anyone wants it at all: none of the three. Five conversations and a landing page answer that before any prototype, and the test-your-idea page is the order to do them in.
The tool decision inside fidelity two and three — Figma Make vs Lovable vs Rork vs Modaal — is the prototyping-tools roundup; this page stops at the fidelity.
The input is the same at every fidelity
Whatever the fidelity, what you type in is a description of what the app does, per scenario, and what is out of scope. At fidelity one it is the designer’s brief; at two and three it is the PRD the tool reads. Writing it once, in the form an agent can build from, is the one piece of work that is never thrown away — the PRD prompt produces it in one page. If the design exists, it is a second input: design-to-code tools covers what the Figma file supplies (layout, tokens) and what it never does (behaviour), which is the PRD’s job.
For the native fidelity, the practical facts: Modaal’s Free plan builds one project with unlimited prompts on one platform, and the project — Xcode and Android Studio — is on your Mac; Pro is €9 per user per month billed annually and adds both platforms together and TestFlight/App Store distribution, on /pricing. The store fees are the same for every route that reaches the store: Apple’s developer program is $99 per year, Google Play $25 once.
The three fidelities
| Click-through (Figma) | Web prototype (Lovable, v0, Bolt, Figma Make) | Native build (Modaal) | |
|---|---|---|---|
| Answers | Is the flow understandable? | Does it work — logic, data, states, complexity? | Does it feel like an app; do people keep using it; do phone features work? |
| Cannot answer | Anything with data or states | Feel on a phone; push, offline, camera, widgets; the store | Nothing a v1 cannot — but it is a v1, not a sketch |
| Input | Frames | PRD, docs, screenshots, Figma | PRD, docs, screenshots, Figma links |
| What is thrown away | Nothing — the frames are the design | The prototype (“Handoff to dev”) | Nothing — the build is the v1 |
| Right when | Discovery; flow tests; roadmap conversations | Web product; “should we build this?”; complexity check | Mobile product; retention or feel question; v1 will be native anyway |
| Test with | Five people, one task | Users and stakeholders on a link | TestFlight / internal track, one week of real use |
Lovable page wording read 23 September 2026; Apple $99/year and Google Play $25 once apply to the native route when it reaches the store.
Frequently asked questions
Building a version of a mobile app to answer a question before the app exists. Three fidelities: a click-through in Figma (does the flow make sense), a working web prototype (does the logic work with real data and states), and a native build (does it feel like an app on a phone and do people keep using it). Each is right for a different question.
A prototype is built to be thrown away once it has answered its question; an MVP is the smallest version real users use, built to be kept. Web prototyping tools produce prototypes that look like products, which blurs the line from one side; native build tools now produce v1s in prototype time, which blurs it from the other. Decide which you are building before choosing the fidelity.
The lowest one that answers the question. Flow and navigation questions: a Figma click-through. Logic, data and complexity questions: a web prototype. Feel, retention and phone-capability questions — or a v1 that will be native anyway: a native build scoped to the PRD’s v1. Writing the question first makes the choice.
Yes, as a web prototype. Lovable’s prototypes page describes turning “tickets, docs, and wireframes into working prototypes”, and its FAQ states it “does not generate React Native projects”, naming a PWA or a Capacitor wrapper as the ways to a phone. Figma Make produces “prototypes” and “web apps”. Both answer working-logic questions; neither answers how the product feels as an installed app.
When the product is a mobile app, the question is about feel or retention, and the v1 is going to be native regardless. Then a web prototype adds a handoff later without answering the question now. A native build from the same PRD, scoped to v1 and tested in TestFlight for a week, answers it and is kept.
By fidelity. A click-through: five people from the target group, one task, watch without speaking. A web prototype: share the link with users and stakeholders and collect feedback on the working flow. A native build: TestFlight or an internal track, a week of real use on their own phones, then the same five-person task test on the real thing.
In store fees, only if it reaches the store: $99 per year for Apple’s developer program and $25 once for Google Play. In tool cost, Modaal’s Free plan builds one project with unlimited prompts, and Pro is €9 per user per month billed annually. In input, the same PRD. In what is thrown away, less: the native build is the v1.
The question you want answered, and a one-page PRD: one sentence, the first user, the scenarios including the empty and failure states, what is out of scope, data and integrations, platform. The PRD prompt page produces it; it is the one artefact reused at every fidelity.
Prototype the version that ships
Attach the PRD. Your own AI agent writes the feature spec you approve, then real SwiftUI and Kotlin/Compose from one project, on your Mac — and TestFlight is one plan away. Free for one project.
Keep reading
- AI prototyping tools for product managers
The seven tools, with the honest column: what happens after the prototype.
- Vibe coding for product managers
Why prototype is no longer the ceiling.
- How to test your mobile app idea
The order of tests before and after the prototype.
- The PRD prompt
The input every fidelity shares.
- Modaal for product managers
Two jobs: prototype to learn, ship the v1.