How to Prototype a Mobile App in Hours (Wireframe → React Native)
TL;DR:
- The wireframe → clickable-prototype → coded-prototype pipeline is now collapsible into a single step
- Four phases: capture wireframe (20-40 min) → generate base app (2-3 min) → iterate visually (1-2 hrs) → install on device via QR (30 sec)
- First testable build: 1-3 hours vs. 2-4 weeks traditional
- Includes an hour-by-hour log of a real 5-screen food-delivery MVP shipped in one afternoon
The three artifacts most guides conflate
Before we get into the workflow, one clarification that trips up most prototyping conversations:
- Wireframe — static layout. No interactivity.
- Clickable prototype — hotspots wired between static screens (Figma, InVision). Can't run real logic.
- Working prototype — real React Native code, real navigation, real state, installable on device via QR.
- Production app — the working prototype plus backend, auth, analytics, store listing.
Most "prototyping" tutorials stop at rung two. The interesting compression is going from rung one straight to rung three.
The four-phase workflow
1. Capture the wireframe (20-40 min)
Any medium that captures screens + elements + tap behavior works: hand sketch, whiteboard photo, Excalidraw, Figma frame, competitor screenshot, or a written paragraph. Treat the wireframe as disposable — its job is to be input to the generator, not a deliverable.
2. Generate the base app (2-3 min)
Feed the wireframe + a one-paragraph description into an AI mobile app builder (RapidNative is what we use — sketch/prompt/screenshot → React Native + Expo → QR preview in one editor, free tier with 20 credits and no card). You get back a live React Native + Expo app with routing, styled screens, and stubbed data. It's about 70% right — good enough to iterate against.
3. Iterate visually (1-2 hours)
The base app has ~30% wrong. Point-and-edit is the accelerator here: click any element in the live preview, describe the change ("make cards rounder, move price to top-right"), and the underlying code updates. Product teams typically do 30-50 micro-iterations in the first hour.
Two rules for this phase:
- Don't accept the first version of any screen.
- Don't over-specify visuals before validating flow. Colors are cheap; navigation is expensive.
4. Ship to real hardware (30 sec)
Scan a QR code, install into a preview client on iPhone or Android, and use the app on real hardware. This is where the bugs Figma can't show you actually show up: thumb-tap zones, safe areas, keyboard behavior, dark mode.
Traditional vs AI-native — the timeline table
For a 5-screen MVP:
| Phase | Traditional | AI-native |
|---|---|---|
| Wireframing | 4-8 hours | 20-40 min |
| Hi-fi design | 2-5 days | Skipped |
| Clickable prototype | 4-8 hours | Skipped |
| Coded prototype | 1-3 weeks | 2-3 min |
| Iteration cycle | 1-3 days per round | 30 sec to 2 min |
| Real-device install | 4-8 hours (Xcode/TestFlight) | 30 sec (QR) |
| First testable build | 2-4 weeks | 1-3 hours |
The compression is mostly the elimination of role handoffs. When one operator drives the whole loop, the "waiting for someone else" hours evaporate.
Which wireframe inputs convert best
Ranked worst → best in signal-to-noise:
- Napkin sketch photo — works, but expect nuance loss. Pair with a written description.
- Whiteboard photo — better; whiteboards force larger, more legible drawings.
- Excalidraw / FigJam — excellent. Digital medium produces clean shapes and labels.
- Figma frame — very good. Layout and hierarchy transfer.
- Written PRD paragraph — underrated. A precise 3-4 sentence description often beats a bad sketch.
- Competitor screenshot — highest signal. Already a mobile UI, so layout, typography, and interaction all transfer.
Hour-by-hour: food-delivery MVP, one afternoon
Two-person team, five screens (restaurant list → detail → cart → checkout → order tracking):
- 0:00-0:30 — Whiteboard sketch, phone photo.
- 0:30-0:38 — Upload + one-paragraph description → base app generated.
- 0:38-1:20 — First iteration pass. Point-and-edit ~40 changes.
- 1:20-1:35 — QR install on both team phones. Two nav bugs surface; fix in 3 min.
- 1:35-2:20 — Send QR to three test users, collect feedback in shared doc.
- 2:20-3:15 — Second iteration pass. Address top-10 UX notes.
- 3:15-3:30 — Publish shareable preview URL, drop in Slack.
Three-and-a-half hours end-to-end, iOS + Android, on real phones.
When to NOT use this workflow
The AI loop isn't universal. Stay traditional when:
- Novel interaction patterns with no precedent (generators pattern-match; no pattern = no output quality).
- Regulated industries (medical, aviation, financial trading) that need documented decision trails.
- Pixel-perfect exec-review demos with no budget for a "70%-then-iterate" opening state.
For the other 90% — CRUD apps, marketplaces, social, dashboards, internal tools — the compressed loop wins on speed, iteration count, and cost.
Wrapping up
The whole compression comes down to one operator driving one loop: sketch it, generate it, poke at it on a real phone, repeat. Curious how the four phases feel end-to-end for others — drop a comment with what you're prototyping, and I'll answer questions for the next couple of days.
Top comments (0)