Guide · the operating loop, for product managers, designers and product marketers
The vibe coding workflow for a mobile app: six steps product people run from idea to both stores
Vibe coding a mobile app is not one long conversation with an AI. It is a loop with six steps, and the people who ship run the same six in the same order: write the one-page PRD, design the screens with references, make the agent plan before it writes code, put every feature on a real phone, decide the backend once, and open the store accounts in week one. This page is that workflow for product managers, designers and product marketers — what each step produces, who owns it, when it is done, and what goes wrong when it is skipped. No code anywhere on the page.
Verified
Why a workflow and not a tool. Every AI builder can produce a first version from a description. What separates the apps that reach the store from the ones that stall in week three is not the builder; it is whether the person building has a document the agent reads every session, a plan step before code, and a phone in their hand after every feature. Those are product-management habits, which is why product people are good at this once they stop treating the chat box as the workflow. The six steps below are the workflow. The chat box is step three.
The loop at a glance
Steps 1, 2, 5 and 6 happen once per app. Steps 3 and 4 repeat per feature until the app is done — that pair is the loop. The table lists each step's artifact, owner and "done when"; the sections after it are the detail and the failure mode.
| # | Step | Artifact | Owner | Done when | Repeats? |
|---|---|---|---|---|---|
| 1 | Write the one-page PRD | PRD file in the project | Product manager / idea owner | A stranger could build the wrong thing from it and you would know why | Once; edited per change |
| 2 | Design with references | One image per screen + the reference pattern as a PRD line | Designer, or PM with a generator | Every PRD screen has a picture | Once for core screens; again for polish |
| 3 | Plan before code | A plan per feature, read and corrected | You read; the agent writes | You changed something in the plan before approving | Per feature |
| 4 | Real phone | TestFlight / Play build on your phone | You; then two people who are not you | You used the feature on the sofa | Per feature |
| 5 | Backend, once | One sentence in the PRD; service under your account | Product manager | Name written down, comparisons closed | Once |
| 6 | Store accounts, week one | Apple + Google accounts in your name; app records created | The publisher (you) | Both dashboards show your name | Once |
Steps 3 and 4 are the loop; the other four happen once per app. No durations by design — they depend on the app.
1. Write the one-page PRD — done when a stranger could build the wrong thing from it and you would know why
Artifact: one page, in plain language, in the project as a file the agent reads every session. Who the app is for; the one job it does on an ordinary day; five to eight screens; what "done" means per screen; what is deliberately out of version one; both platforms or one, decided on purpose. Owner: the product manager, or whoever owns the idea. How: the PRD prompt produces it from six questions; in Modaal, the Refine step writes it to a PRD.md at the root of the project. What breaks without it: the agent re-decides the architecture every session, features contradict each other, and the third week is spent explaining to the agent what the app is. The PRD is the same document whether an agent, a developer or an agency builds; it is the one asset that survives switching tools.
2. Design the screens with references — done when every screen in the PRD has a picture
Artifact: one image per screen, plus the reference you copied the pattern from. Owner: the designer, or the PM with a design generator. How: draw the screens in Figma or generate them with a design tool such as Google Stitch or Claude Design; check a reference library — Mobbin covers iOS, Android and web — for how shipped apps in your category handle onboarding, the paywall, empty states. Write the pattern into the PRD as a line ("onboarding: three screens, permissions at the moment of use"), not the screenshot. Mobile app design reference tools has the libraries; mobile app prototyping has which fidelity to stop at. What breaks without it: the agent invents layouts, every screen looks like every other AI app, and the paywall is a wall of text. Do this at the start for the core screens and again later for polish; the second pass is where reference libraries earn their price.
3. Plan before code, one feature per session — done when you have read the plan and changed something in it
Artifact: a plan per feature — which screens, which data, what the agent will change — as text you read before any code exists. Owner: you, reading; the agent, writing. How: paste the PRD, name one feature, and ask for the plan, not the build. In Modaal that is Plan mode: from the documentation, "a structured implementation plan (a feature spec) without writing code." Read it. Correct what is wrong — the agent has misread a screen, added a setting you did not ask for, skipped the empty state. Then approve, and let it build that one feature. What breaks without it: the agent takes the app in a direction you find out about forty minutes of tokens later; "make it nicer" prompts pile up; and the cost of the AI subscription doubles on rework. This is the step that keeps the rest of the loop inside one subscription, and it is the one product people are best at, because a plan review is what you already do with engineering. Spec-driven mobile app development is the argument in full.
4. Put every feature on a real phone — done when you have used it on the sofa
Artifact: a build on your own phone after every feature, through TestFlight on iPhone and the Play testing track on Android. Owner: you, and from the third feature, two or three people who are not you. How: the builder produces the build; you install it and use the feature the way a user would, not the way a tester would. In Modaal, builds run locally on your Mac and go to TestFlight from the app. What breaks without it: the simulator says yes to things a phone says no to — keyboard behaviour, a gesture, the notification that opens the wrong screen — and you discover ten of them at once in week six instead of one at a time. The PRD's "done when" lines are the test script; each is a thing a tester either could or could not do.
5. Decide the backend once — done when you have written the name down and stopped reading comparisons
Artifact: one sentence in the PRD: which backend, under whose account. Owner: the PM, in the first week. How: pick a service you hold the keys to — Supabase or Firebase are the common choices for product people — and open it under your own account, not the builder's. If the app charges money, decide the paywall vendor at the same time and write the products, entitlements and trigger into the PRD; Apple's guideline 3.1.1 asks for "a restore mechanism for any restorable in-app purchases", so the restore control goes in the spec now. Paywall tools for iOS and Android has the vendors on their published terms. What breaks without it: half the "the AI keeps breaking my app" stories are a backend changed in the middle; auth, data fetching and storage all change shape with it, and every feature built before the switch is rebuilt.
6. Open the store accounts in week one — done when both dashboards show your name
Artifact: an Apple Developer Program membership ($99 a year) and a Google Play Console account ($25 once), both in your name, with the app record created. Owner: whoever will be the publisher — you, not a contractor and not the builder. How: Apple developer account setup is the walkthrough; Google's takes an afternoon. Create the app records now so TestFlight and the Play testing track work from the third feature onwards. What breaks without it: the accounts take days to approve, review takes days more, and the two together are the one part of the timeline you cannot compress; teams that open the accounts in launch week lose launch week. Submit early with "manually release this version" and hold it. App Store rejection reasons is the list to read before the first submission.
The weekly rhythm once the loop runs
After steps 1, 2, 5 and 6 are done once, a working week looks like this: pick one feature from the PRD; ask for the plan; read and correct it; approve; build; install on the phone; use it; write what is wrong as a one-line change to the PRD, not as a prompt; repeat. Every fourth feature, hand the build to two people who are not you and watch them without talking. Every time the PRD changes, the agent reads the new version next session, which is why the change goes in the document and not in the chat.
The tool matters less than the loop, and the loop is what Modaal is built around: the PRD at the root, a plan you approve before code, your own AI agent on the subscription you already have, builds on your Mac to TestFlight, and native iOS and Android apps from one project — each feature's logic written once, rendered in SwiftUI on iPhone and Jetpack Compose on Android, with the Xcode and Android Studio projects on your disk on every plan. The Free plan covers one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually, €15 monthly, and adds both platforms, TestFlight and Git — /pricing. Modaal for product managers has the same loop from the product side.
Frequently asked questions
A repeatable loop rather than one long conversation: write a one-page PRD the agent reads every session; design the screens with references; make the agent produce a plan per feature and approve it before code; put every feature on a real phone; decide the backend once; open the store accounts in week one. Steps three and four repeat per feature; the rest happen once.
Yes, and the parts of the workflow that decide whether the app ships — the PRD, reading the plan, testing on a phone, deciding scope — are product-management work. The tool writes the Swift and Kotlin; in Modaal the agent writes a plan you approve, builds one feature at a time, and the native projects stay on your disk for an engineer to join later.
The one-page PRD: who the app is for, the one job, five to eight screens, what done means per screen, what is out, and which platforms. It is the file the agent reads every session and the same document a developer or agency would build from. The PRD prompt produces it from six questions.
Because a plan takes a minute to correct and code does not. Reading a plan for one feature catches a misread screen, an extra setting or a missing empty state before the agent spends tokens building it; approving one feature at a time keeps the app going in the direction the PRD says. Product people are good at this because plan review is what they already do with engineering.
After every feature, on your own phone, using it as a user would; from the third feature, also with two or three people who are not you. The simulator misses keyboard behaviour, gestures and notification routing; finding those one at a time is the point of the loop.
In week one. Apple’s Developer Program is $99 a year and Google Play is $25 once; both take time to approve, and app review takes more, and neither can be compressed. Opening them early also makes TestFlight and the Play testing track available from the third feature. Publish under your own accounts, not a contractor’s or a builder’s.
One you hold the keys to, under your own account, decided once and written into the PRD; Supabase and Firebase are the common choices for product people. Changing the backend mid-project changes auth, data fetching and storage together, which is behind many “the AI keeps breaking things” stories.
One AI subscription you already have; a builder that lets the agent plan before it writes and puts builds on your phone; a design tool or generator plus a reference library for step two; a backend under your account; TestFlight and the Play testing track, which come with the store accounts. In Modaal the builder runs on your own agent and produces native iOS and Android apps from one project; the loop is the same with any builder that has a plan step.
Run the loop tonight: PRD, plan, phone
Modaal is built around this workflow — the PRD at the root, a plan you approve before code, builds to TestFlight from your Mac, and native iOS and Android apps from one project with your own AI agent. Free for one project.
Keep reading
- The PRD prompt
Step 1, produced from six questions.
- Mobile app design reference tools
Step 2, the libraries by platform coverage.
- Spec-driven mobile app development
Step 3, the argument in full.
- How to make an app: the seven decisions
What to decide before the loop starts.
- Modaal for product managers
The same loop from the product side.
- Why your vibe-coded app breaks on every new feature
What the loop and the spec protect you from.