Guys, this is the post I wish I had 6 months ago. Genuinely.

If you’ve ever tried to build an app before, you know the hellscape I’m talking about of failures and nothing working until everything suddenly works. One battle after another trying to get your app to work on simulator. Metro issues. Syntax errors. Render problems. CocoaPods. Hermes. Compatibility problems.

Just you and your patience copy and pasting logs and trying to debug.

Then crossing fingers as you hope it works this time just to crash on your device. Then crashing some more.

When I made my first app, Good Times, I spent a full day and a half trying to get anything to show on my screen. My computer was lucky to make it out alive because I was having my temperance tested and almost gave up a few times.

I’d designed the app, got the code in place, but with apps you can’t see anything you’ve done to start testing and iterating until you get a working build. You can’t preview it like a website in a local browser. And a working build is not a simple thing to get, certainly not as a first time app builder.

So, I battled getting more and more frustrated because I wasn’t able to do any creative work. The fun stuff.

Nobody likes seeing red. More red. And then some more red.

When I made Little Moments (second app), I got a bit better at this. I got to the point where I could actually see something quite a bit faster. But still a solid few hours of tug of war to get there. Crashes had not escaped me.

So, today, I’ve written down a comprehensive solution. The exact tools, order of operations, and context you need to get a working build on your simulator first time (not hours), and an on-device build from Test Flight that works first time (not hours).

I’ve also recorded a unpolished real-time video (apologies for being in my PJs and sleepy), sharing my screen and showing you how we go from 0, to app on your phone in under 90 minutes. It’s even faster than that with my boilerplate template which I’ve tweaked since this video to improve even more.

I walk you through the steps, but there’s also a done-for-you, single copy and paste, and battle-tested prompt that gives you everything you need for first time builds. Just copy it, paste in in your coding agent of choice, and in under 50 minutes you’ll have a working app ready to view on your simulator and start making your one.

I wish I had this when I started, but as they say, the next best time is right now.

Let’s go over it.

I always thought the hard part of building an app is the app. That they were much harder than web.

They are harder. But not as unattainable as I thought, especially with tools like Expo.

The hard part of building an app—at least the first few ones when you're non-technical and learning to vibe code, is getting from a blank machine to a working build of a blank app on your actual phone. Most of my early frustration came from a mismatch between what I thought was hard and what was actually hard (libraries, configs, certs, build and submission quirks, that one damn dialog box that won't go away).

Once I had a stable, boring, empty app live on my phone via TestFlight (Apple's beta testing tool), every single thing after that got dramatically easier.

So here's the move I know preach:

Get a placeholder app with any skeleton live before you build your actual full one.

I call this The Greenfield Rule. Put pipeline and build chain first. Product second.

Or more quaintly put: stable empty app beats broken beautiful app.

Because once you have a stable workflow of seeing your app, being able to submit it and view it on your phone and it doesn’t crash, everything else—every feature, every design change, every whatever— is so much faster because it works.

A big part of the battle is the beginning. The first working build.

And that’s what I want you to get from this post. Proof that the first working build is easy so you can start making whatever app you want.

On Saturday AM I recorded myself going from "I have nothing on this machine" to "an app I made is on my phone, signed in, with a basic home screen." Top-to-bottom, no edits, no cuts. Under 2 hours as a non-technical builder. If you've used a terminal before and prompted Cursor before, more like 50 minutes.

Compare that to that 6-months-ago spending hours/days. That gap isn't talent, trust me. That gap is order of operations.

Ok, below is the exact order written out. With links, cost, and a note on what to skip.

Start here.

First collecting necessary credentials and installing things. No code yet. I'll explain what each tool is, why I picked it, the alternatives, and exact steps. Skip the "why" if you trust me but read it once, because choosing the right stack early saves you downstream regret/debt.

1. Apple Developer account ($99/yr — ~10 min)

Head to developer.apple.com, click Account → Enroll, sign in with your Apple ID. Verify a phone number, accept the agreements, and pay the $99. Apple takes about 24 hours to verify (sometimes faster), but you can keep going while you wait.

Why: It's the price of admission. You cannot push a build to TestFlight or the App Store without it.

Alternatives: none. Apple has a monopoly here.

2. Cursor (free trial → $20/mo — ~2 min)

Download from cursor.com, sign in with email or GitHub. Cursor is a code editor (a fork of VS Code) with an AI agent baked into the sidebar. You describe what you want, it edits files, runs terminal commands, plans changes, and basically operates your codebase from chat.

Why Cursor: the agent mode is the unlock for non-technical builders. You don't need to know syntax, you describe outcomes. It’s like Claude Code but with more coding tools.

Alternatives: Claude Code (the app version or terminal version), Windsurf (very similar to Cursor), VS Code + Copilot (more manual). For this guide we're using Cursor.

3. Supabase (free tier — ~3 min)

Sign up at supabase.com, click New Project, give it a name, set a database password (save it in your notes file — you'll never need it again but you'll regret losing it), pick a region close to you, hit create. While it spins up (~2 min), go to Project Settings → API. Copy the Project URL and the anon key into a notes file.

The anon key is your project's public API key — it's safe to ship inside your app because Supabase enforces row-level security on the server side.

What Supabase is: your backend in a box — Postgres database, auth (email, social, magic links), storage, edge functions, all under one dashboard.

Why: it has a clean React Native SDK, costs $0 until you have real users, and the SQL editor is genuinely good.

Alternatives: Firebase (Google's version — also great, but I prefer Postgres), Convex, or rolling your own Node.js + Postgres stack (don't, not yet).

4. Expo (free — ~2 min)

Sign up at expo.dev. Don't create a project on the website — your project gets created automatically when you run the boilerplate given in Phase 2.

What Expo is: a framework on top of React Native that handles the entire iOS build pipeline for you — hot reload, over the air updates saving builds and submissons, push notifications, TestFlight submission, the works.

Why Expo: it's the only realistic way for a non-technical builder to ship to iOS.

Alternatives: React Native CLI (more manual, more pain, more time in Xcode), pure Swift (you'd need to actually learn iOS), Flutter (different ecosystem).

5. GitHub (free — ~3 min)

Sign up at github.com. Click New repository, name it whatever (you can rename later), set it to Private, do not check "Initialize with README" — we want a clean empty repo. Hit Create.

The next page shows you a URL like https://github.com/your-username/your-repo.git. Copy this. You'll paste it into Cursor in step 9.

What it does: GitHub is where your code lives in the cloud. If your laptop dies, your code is fine.

Why now: EAS (Expo's cloud build service) reads from GitHub, and so does pretty much every CI/deploy tool you'll ever touch. Alternatives: GitLab, Bitbucket — GitHub is the default for a reason.

6. PostHog (free — ~2 min)

Sign up at posthog.com, choose the cloud option (US or EU — pick whichever is closer to your users). You'll land on a project dashboard. In Project Settings → Project API Key, copy the key into your notes file.

What PostHog is: product analytics — every tap, screen, funnel, retention curve. Plus session replays, feature flags, and an AI chat that lets you ask questions in plain English.

Why install on day 0: retrofitting analytics later means you broke an event somewhere and don't know which dropoff is real.

Alternatives: Mixpanel, Amplitude. PostHog wins on the free tier (1M events/mo), the MCP, the AI, and cost in general. Just stellar. The boilerplate gives you this install too so in your one copy and paste, you’ll get it installed.

7. RevenueCat (free under $2.5K MRR — ~3 min)

Sign up at revenuecat.com if you plan to make money with your app. You don't need to set up products yet — just create the account. So fast and easy.

What it does: handles paywalls, subscription management, receipts, cancel flows, A/B tests on offers. Wraps the Apple StoreKit nightmare into a 5-line SDK.

Why install early even if you're not charging yet: the SDK is easier to wire into the boilerplate now than to retrofit into a finished UI you don't want to touch.

Alternatives: Direct with Apple Payments, or Stripe (no native iOS subscription handling for you to do any payments in app).

8. Xcode (free — ~30 min to download in the background)

Open the Mac App Store, search Xcode, install. It's ~12GB so kick this off first and let it run while you do the other steps.

Why you need it: Xcode bundles the iOS Simulator (a virtual iPhone on your Mac), Apple's command-line build tools, and the signing/provisioning machinery that Expo relies on under the hood. You will not write code in Xcode. You will use it exactly twice: to install once, and to confirm the simulator works.

Alternatives: none — if you're targeting iOS, you need Xcode.

9. Clone your empty repo into Cursor (~2 min)

Open Cursor. From the welcome screen click Clone Git Repository (or File → Clone Git Repository). Paste the GitHub URL from step 5. Pick a folder on your Mac for it (Documents/Projects works). Click Open.

What cloning does: copies your empty GitHub repo to your laptop and links the two together so future commits and pushes know where to go. You'll now see an empty folder open in Cursor's sidebar. This is your working app — currently nothing in it but a .git folder.

10. Check in.

Spend so far: $99. Time: ~30-45 minutes. You should now have:

Now we’re in great shape to enter Phase 2…the part that gives most people a kicking.

This is the phase where most non-technical builders usually takes many hours, not 50 minutes.

You can skip it. But after doing this process myself, I will never skip it again.

The goal of this phase is not your app yet. The goal is a working build, on your phone (and simulator), of a boring template: splash screen → auth screen with email sign in → 2 basic onboarding screens → home with 4 tabs → Settings. That's it. No features. No design. No logic. Just dial tone.

Why? Because every "library compatibility hell" issue you'll ever hit on this stack will hit you here, before you've poured hours into a feature that now won't compile. You debug the stable template once. You don't debug your unique app's setup forever.

You don't need my boilerplate. You can absolutely write a PRD, ask Cursor or Claude to scaffold an Expo + Supabase app from scratch, and prompt your way through it. I've done that too. You will run into errors though. Things will fail. It will be annoying. That's just the truth.

If you'd rather skip the red error screens and have me hand you a battle-tested setup, here's exactly what to do.

Grab the boilerplate prompt below.

I priced it cheap on purpose and it’s 50% off for the next week. $50 is much less than a day of getting stuck on a weekend, and infinitely less than the cost of giving up. And it will get you to the fun creative work much faster with a proper app architecture that works.

Try it. If it doesn’t work for you for whatever reason or you’re just not happy, I’ll either get on a 1:1 call with you to help you setup and get your app working, or just give you the money back.

Quick aside on why a boilerplate matters more than I realised at first. Simon Willison was on Lenny's pod a few weeks back making a point that stuck with me — every new project he starts, he starts with a thin template. A 1+1=2 test. A bit of formatting. His house style baked in. The reason isn't for him: "agents are phenomenally good at sticking to existing patterns in the code. If you give them a code base that already has [patterns], they will pick that up and roll with it."

So your $50 boilerplate isn't just saving you the Saturday. It's training every Cursor prompt that follows. Stable empty doesn't just unblock you — it teaches the AI the style you want. That's a second-order win I didn't see until someone else said it out loud.

End of this phase: you should be looking at the iOS simulator with a working basic app that looks nothing like your idea, fully signed in. If you're not there, stop and fix it before moving on. Do not build a feature on top of a wobbly foundation.

You're now standing in front of a working app foundation that works. You’re in place to start running the fun race and getting creative. But before getting fancy yet. I suggest practicing the core rhythm of change/build/submit to feel the workflow.

Here’s what to do, after you’ve done Phase 2.

That's the whole loop guys. Every feature you'll ever ship for the rest of this app's life is some variation of this loop. Faster, more confident, more interesting code in the middle. Same loop though.

Now you can start it again. Go to Cursor. Start changing your boilerplate to a real app that solves your problem. You can focus on screen by screen, or work in Plan Mode to spec your entire feature set. Cursor will build it for you and it will work.

As you add more credentials like Google or Apple or Anthropic/OpenAI if you’re doing AI features, make sure you get your agent to add them in .env (local) and in EAS credentials. The reason for this is your .env file does NOT to to github because that would mean your keys are available to the public (bad). EAS credentials makes sure what you need for your app to work on other devices that don’t have your .env is available.

I'm going to start linking this post every time someone asks me "how do I actually start building an app?" — because I've gotten that question maybe 15 times this month and I keep typing the same paragraphs to friends or folks on LinkedIn.

The honest answer is: the gap between you and a live app on your phone is one focused afternoon. Not a bootcamp. Not a CS degree. Not waiting for permission. One afternoon and it’s a great personal milestone to see an app that’s yours working.

Make any little app idea you have. Share it with a friend. It could be your flavor of a breathing app, a calorie app, a camera app. It’s all possible. Just make something.

The only two things to remember when you sit down: the build chain is the hard part, and the boilerplate/master prompt is the unlock. Buy back the time and make sure you get your app live. Use my prompt, $99 Apple account, $20 of Cursor credits. Time is the expensive thing.

If that's the part keeping you stuck — the fear of the build chain — I hope this is the kick. It’s really not that hard to make something awesome.

If you do it, hit reply and send me a screenshot of whatever you build and I’ll feature it. I genuinely want to see whatever you make.

That's the starting gun. ☝️ Then you get to run.

Hope this was interesting.
— Jaryd (view my stack of non-negotiable building tools here)