Planning a Mobile App Before You Prompt

The difference between a mobile app that comes together in a weekend and one that turns into a tangle of half-broken screens is almost never the prompting. It's the planning. Ten minutes deciding what you're building saves hours of the AI confidently building the wrong thing.

This guide gives you a planning checklist you can reuse for any app. Fill it out in a plain text file, keep it open, and paste the relevant parts into your prompts as you go.

Step 1: Write the one-sentence core loop

Before screens, before features, answer this: what does a user open the app to do?

A user opens the app to log a workout and see their streak.

If you can't say it in one sentence, you don't have an app yet — you have a pile of features. The core loop is your north star. Every screen either serves it or gets cut for v1.

Step 2: List the screens

Write down every screen the app needs. Keep it flat and boring:

- Onboarding / sign in
- Home (today's workout + streak)
- Log workout
- History
- Workout detail
- Settings

Six to eight screens is a healthy v1. If your list is twenty screens long, you're planning v3. Circle the two or three screens that directly serve the core loop — those get built first.

Step 3: Draw the navigation map

Screens aren't enough; the AI needs to know how they connect. Sketch the structure — you don't need a design tool, indentation works:

Tabs:
  Home
    -> Log workout (modal)
    -> Workout detail (push)
  History
    -> Workout detail (push)
  Settings

This tells the AI three things it would otherwise guess wrong: what's a tab vs. a stack, what opens as a modal vs. a pushed screen, and which screens are reachable from where. Mobile navigation is opinionated — deciding this up front prevents the AI from inventing a structure you'll have to unwind.

Step 4: Define your data

List the things your app stores and their fields. This becomes your data model:

Workout
  - id
  - date
  - type (run | lift | yoga)
  - durationMinutes
  - notes

User settings
  - reminderTime
  - units (metric | imperial)

Then answer two questions that shape the entire build:

• Where does this live? On-device only (local storage / SQLite), or synced to a backend? On-device is dramatically simpler and free — start there unless you truly need multi-device sync or accounts.
• Does it need to work offline? Most mobile apps should. Decide now, because retrofitting offline support later is painful.

Step 5: Note the platform realities

A short list of constraints keeps the AI from generating web-shaped code that breaks on a phone:

• Permissions — camera, location, notifications, photos. Each needs a justification string, and each requires the user to approve it. List which ones you need.
• Safe areas — notches and home indicators. The AI should respect SafeAreaView; remind it.
• The Android back button — a hardware/gesture back exists on Android and not iOS. Navigation must handle it.
• Keyboard — forms need to scroll so the keyboard doesn't cover inputs.

You don't have to solve these now. You just have to name them so they're in the plan.

Step 6: Turn it into a spec the AI can read

Combine the above into one document — call it SPEC.md — and keep it in your project. A good spec is short:

# App: Streak

## Core loop
User logs a workout and sees their streak.

## Stack
Expo + React Native, TypeScript, Expo Router.
On-device storage (SQLite). No backend for v1. Offline-first.

## Screens & navigation
Tabs: Home, History, Settings.
Home -> Log workout (modal), Workout detail (push).
History -> Workout detail (push).

## Data
Workout { id, date, type, durationMinutes, notes }
Settings { reminderTime, units }

## Platform notes
Notifications permission for reminders. Respect safe areas.
Handle Android back. Forms scroll above keyboard.

Now your prompts get short and precise because the context lives in the spec:

Using SPEC.md, build the Log workout modal screen. Form fields for type, duration, and notes; save to SQLite; dismiss on save.

Step 7: Sequence the build in vertical slices

Don't build all screens then wire them. Build one vertical slice at a time — a single screen that works end to end, from UI to data and back:

1. Home screen showing a hardcoded streak (proves layout + navigation).
2. Log workout saving to real storage (proves the data layer).
3. Home reading the real streak from storage (closes the core loop).
4. Everything else — history, detail, settings — one slice at a time.

After slice 3 you have a working app doing its one job. That's the moment to test on a real device and decide what's actually worth adding.

The planning checklist

Copy this into a file for your next app:

[ ] Core loop in one sentence
[ ] Screen list (circle the 2-3 core screens)
[ ] Navigation map (tabs / push / modal)
[ ] Data model (entities + fields)
[ ] Storage: on-device or backend? offline: yes/no?
[ ] Platform notes (permissions, safe areas, back button, keyboard)
[ ] SPEC.md written
[ ] Build order: vertical slices, core loop first

Ten minutes here changes the whole build. The AI is a fast, tireless builder — but it builds exactly what you point it at. Point it well.

Next steps

• Now write the prompts: Prompt Strategies for Vibecoding Mobile Apps
• Start building: Vibecoding an iOS + Android App with Expo