Vibe Code Your First
Mobile App.

You end up with: A picture of the finished product, a written PRD, a screen map, a design system, and a project file the agent reads before every task.

1. What you will build The app you ship at the end of this course, and the six pieces it is made of. soon
2. Pick an idea you can finish How to cut a big idea down to something that fits in one thumb and one weekend. soon
3. How your app gets on a phone Three ways to ship to both stores, and what each one costs you. soon
4. Write the PRD with the agent Interview yourself on paper, then let the agent turn it into a spec it can build from. soon
5. Map the screens Screens before schemas. Draw the flow first, and the data model writes itself later. soon
6. Choose a look you can defend Pick type, colour and spacing once, write it down, and stop redeciding it every screen. soon
7. Teach the agent your project The CLAUDE.md file: house rules that survive every new session and every new chat. soon

You end up with: A React Native app you can open on your own phone, with screens that connect, backed up on GitHub.

1. What a mobile app is made of Screens, components, state and the bundle, explained without a single line of jargon. soon
2. Scaffold the project Let the agent create the project, and understand what each folder it made is for. soon
3. Run it on your phone Expo Go, the simulator, and the difference that matters when something looks wrong. soon
4. Read what the agent wrote You do not need to write code, but you do need to recognise what it is doing. soon
5. Connect the screens Navigation, tabs and the back button, so your app stops being a pile of pages. soon
6. Save your work Git and GitHub for people who have never used them, and why every change gets its own commit. soon
7. When it breaks Read the error, find the file, describe it to the agent, and get moving again in five minutes. soon

You end up with: A Supabase database with your tables, your app reading and writing to it, and security rules that hold.

1. What a database is, for a product person Tables, rows, columns and relations, using your own app as the example. soon
2. Design your tables Turn your screen map into a schema, and catch the three mistakes that hurt six weeks later. soon
3. Set up Supabase A project, your tables, and the keys that connect your app to them. soon
4. Read and write data Create, read, update, delete, whether you talk to the database directly or through an ORM. soon
5. Decide who guards your data Row Level Security, when it protects you, and when the job moves to your own code. soon
6. Change the schema safely Migrations, so adding a column tomorrow does not break the app people are using today. soon

You end up with: Working sign-in with email and Apple, protected screens, user profiles, and transactional email that sends.

1. What signing in really does Sessions, tokens and refresh, so you can tell a login bug from a data bug. soon
2. Add email sign-in Supabase Auth, magic links, and the sign-up flow that loses the fewest people. soon
3. Add Sign in with Apple Not optional if you offer any other social login, and the reason apps get rejected. soon
4. Protect the right screens The logged-out state, the loading state, and what a stranger is allowed to see. soon
5. Send email that arrives Resend, your own domain, and the DNS records that keep you out of spam. soon

You end up with: A marketing site on your own domain, live on Vercel, linked to the app in both directions.

1. Why your app needs a website Nobody finds an app in the App Store. They find it somewhere else first. soon
2. Build the site A fast marketing site the agent can build in an afternoon, in Astro or Next.js. soon
3. Deploy to Vercel Your domain, HTTPS, and a preview link for every change before it goes live. soon
4. Link the web to the app Deep links and universal links, so a link in an email opens the right screen. soon
5. The pages the stores require Privacy policy, support page and account deletion. Missing one of these blocks review. soon

You end up with: An Edge Function for the small jobs, a Modal endpoint for the heavy ones, and one AI feature users can feel.

1. What belongs on a server The test that tells you whether code goes in the app or behind it. soon
2. Edge Functions for small jobs Supabase Edge Functions: webhooks, scheduled work and anything holding a secret. soon
3. Modal for the heavy jobs When a job needs a GPU, a minute, or a Python library, it runs on Modal. soon
4. Add an AI feature Call the Claude API from your backend, stream the answer, and know what each call costs. soon
5. Keys that must never ship Anything inside your app can be read by anyone. Where secrets actually go. soon
6. When things are slow or fail Timeouts, retries and loading states, so a bad network is not a bad review. soon

You end up with: Stripe checkout on the web, subscriptions in the app, and a database that knows who paid.

1. The thirty percent rule When Apple must take a cut, when it may not, and how that decides your whole pricing page. soon
2. Stripe on the web Checkout, the customer portal, and subscriptions that people can cancel themselves. soon
3. Subscriptions in the app In-app purchase in React Native, and why RevenueCat is worth the fee. soon
4. How your app learns someone paid Webhooks, and the failure mode where the money arrives but the feature does not unlock. soon
5. Test payments without spending money Test mode, sandbox accounts, and tunnelling a live webhook to your own laptop. soon
6. Design the paywall Where to put it, what to give away, and the trial length that converts. soon

You end up with: Automated review on every change, tests that run in CI, crash reporting, and a way back from a bad day.

1. Why AI-written code rots The three failure patterns, and the habits that prevent each one. soon
2. Review every change CodeRabbit on every pull request, giving you a second opinion you did not have to hire. soon
3. Tests you will actually keep Test the five things that would embarrass you, and skip the rest without guilt. soon
4. Know it broke before users do Crash reporting and the four numbers worth watching in week one. soon
5. Undo a bad change Rewind, revert, branch. Getting back to working software in two minutes, not two days. soon
6. The security pass The checklist to run before anyone who is not your friend can sign up. soon

You end up with: Your app live on the App Store and Google Play, and a way to push updates without waiting for review.

1. What Xcode and Android Studio are for You barely use them, but you cannot ship without them. Here is the part you need. soon
2. Icons, screenshots and store copy The assets both stores demand, and the listing that makes people tap install. soon
3. TestFlight and your first ten testers Get the app into real hands before a stranger reviews it. soon
4. Surviving App Store review The seven rejection reasons that catch first-time builders, and how to answer each one. soon
5. Google Play and the testing requirement Play now demands weeks of closed testing. Start it early or wait. soon
6. Ship updates without a review Over-the-air updates: fix a typo this afternoon instead of next week. soon

You end up with: A working loop: something breaks, you hear about it, you fix it, you ship it.

1. Your first bug report from a stranger Reproduce, isolate, fix, ship. The loop that turns a complaint into a release. soon
2. What the numbers tell you Retention, activation and the one metric worth building the next feature around. soon
3. What it costs at ten, a thousand, and a hundred thousand users Real numbers for this stack, and the line item that surprises everyone. soon
4. When to hire a developer The four signals, and the questions to ask so you can tell good from expensive. soon
5. What to build next Where this course ends and what the second app should be. soon