I quit learning to code three times.
Not because I wasn't motivated. I had app ideas I genuinely wanted to build. I bought courses, watched tutorials, followed roadmaps. Every single time, I hit the same wall: the resources assumed I already understood something I didn't, and by the time I'd filled that gap, three more gaps had appeared behind it.
Then I stopped trying to learn to code first and started trying to build first — using Claude Code as my development partner.
Six weeks later I had a working habit tracker and an AI-powered calorie tracker on the App Store.
This is the workflow I used, documented chapter by chapter. I've since turned it into a complete book for anyone who's been in the same place I was.
Mobile app development has been evolving for thirty years. In the 1990s and early 2000s, building software required deep technical expertise — compilers, memory management, hardware constraints. In the 2000s through 2020s, frameworks like React Native and tools like Expo dramatically lowered the barrier. But it was still a barrier measured in months of learning before you could ship anything real.
We are now in a third era. AI partners like Claude Code understand your entire project at once — not just the file you're editing, but the relationship between your components, your database schema, your API calls, and your navigation structure simultaneously.
The implication is significant: the bottleneck is no longer technical knowledge. It's the ability to describe what you want clearly.
That is a learnable skill, and it's the core skill this workflow develops.
The setup stack is deliberately minimal:
The key insight here is that you are not setting up a traditional development environment where you write code in files. You are setting up a conversation interface where you describe screens, features, and behaviours — and Claude Code builds them.
The first project you build in this environment is not an app. It is a "Hello World" screen you get running on your physical phone in under 20 minutes. This matters psychologically: seeing your name on a real phone screen, the first time, breaks the mental model that this is hard.
Before writing a single line of app logic, you prove the pipeline works end to end:
This is called the Three-Stage Testing Protocol: Computer → Mirror (screen mirroring on your laptop) → Physical Phone. Every feature you build gets tested through all three stages before you move on. It catches 90% of layout bugs that only appear on real hardware.
This protocol sounds simple. It saves enormous amounts of frustration later.
Before building anything complex, it is worth understanding what makes an app work — not technically, but structurally.
The Five-Element Framework breaks every successful app into five layers:
Layer 1 — Core Function
The one thing your app does brilliantly. Not ten things. One. A calorie tracker counts calories. A habit tracker tracks habits. If you cannot state your app's core function in five words, the app is not ready to build.
Layer 2 — Core Loop
The repeatable cycle that drives daily engagement. For a habit tracker: open app → check habits → mark done → see streak. The loop must be completable in under 60 seconds or users will not return.
Layer 3 — Accessory Features
Enhancements that orbit the core without changing it. Statistics. History. Reminders. These are built after the core loop works perfectly — never before.
Layer 4 — Surface Area
Every screen and interaction the user touches. The fewer screens, the better. Every additional screen is a navigation decision the user has to make.
Layer 5 — Retention Hook
The reason users come back tomorrow. Streaks. Progress indicators. Completion percentages. This is what separates apps people use once from apps people use every day.
This framework is the difference between building something that works technically and building something people actually use.
The first real project is a habit tracker that stores everything locally on the device using AsyncStorage.
Why start local? Because local storage is instant. There is no network, no authentication, no database to configure. You can see the full app working on your phone within a few hours and the workflow is pure: describe the feature, Claude Code builds it, test it on your phone, iterate.
The app includes:
The prompting workflow that works:
"Build a habit tracker screen. It should show a list of habits,
each with a checkbox. When I check a habit it should mark it
as done for today. Show a streak counter at the top that
increments each day all habits are completed."
That single prompt, given to Claude Code in a properly scaffolded Expo project, produces a working screen. You then iterate:
"Add a way to create new habits. Show a text input at the
bottom with an Add button."
"The habit list is getting long. Add a scroll view."
"When I swipe left on a habit, show a delete option."
This is the workflow. Describe → Build → Test → Describe again.
Important:During development, Claude Code may add hidden panels for testing — data reset buttons, debug toggles. These must be removed before you submit to the App Store. Audit for these before every submission.
Local storage works for a single device. The moment a user switches phones, or wants their data on a tablet, it breaks.
The solution is Supabase — an open-source Firebase alternative that gives you a PostgreSQL database, authentication, and real-time subscriptions with minimal configuration.
The upgraded habit tracker adds:
The local cache + cloud sync pattern used here is worth understanding:
Writes go to AsyncStorage first (instant feedback), then sync to Supabase in the background. Reads come from AsyncStorage unless it is empty, in which case Supabase is the source of truth.
This gives the app the feel of a local app (instant response) with the durability of a cloud app (data survives phone changes).
The Supabase dashboard is entirely visual — you create tables, set up auth, and configure security policies through a browser interface. No SQL knowledge required for the basics.
This is where things get genuinely impressive.
The third project adds the Anthropic vision API to the app. The user opens the camera, photographs their meal, and the app returns a nutritional breakdown: calories, protein, carbohydrates, fat. Automatically. From a photo.
The implementation:
The prompt sent to Claude with each image:
Analyse this food image and return a JSON object with:
- calories (number)
- protein_g (number)
- carbs_g (number)
- fat_g (number)
- food_name (string)
- confidence (low/medium/high)
Return only valid JSON, no explanation.
Requesting JSON output is essential. Structured JSON responses can be directly consumed by the app without fragile text parsing.
The accuracy is genuinely useful for everyday logging — not clinical-grade, but good enough for the use case.
Here is a problem that most beginner tutorials skip entirely, and it causes real security vulnerabilities:
You must never put your Anthropic API key inside your mobile app.
A mobile app is a file that gets installed on millions of devices. Anyone can extract the binary and read hardcoded strings inside it — including your API key. If your key is exposed, anyone can run up unlimited API charges on your account.
The correct architecture:
Mobile App
↓ (sends image, no API key)
Supabase Edge Function
↓ (adds API key securely, forwards request)
Anthropic API
↑ (returns result)
Supabase Edge Function
↑ (forwards result)
Mobile App
The Edge Function lives on Supabase's servers. The API key is stored as an environment variable on the server. The mobile app never sees it.
Claude Code builds this Edge Function from a plain English description. You deploy it with a single command. The security model is correct from day one.
EAS (Expo Application Services) handles the build and submission process:
eas build --platform ios
eas submit --platform ios
eas build --platform android
eas submit --platform android
EAS compiles your Expo project into a native binary in the cloud. You do not need Xcode installed. You do not need a Mac to build for iOS (though you do need an Apple Developer account, $99/year).
The submission process for both stores requires app description and keywords, screenshots, a privacy policy URL, and an age rating questionnaire.
Six weeks from knowing nothing to apps on the App Store.
That timeline is real. It is not a marketing claim. The limiting factor was not technical difficulty — it was learning to describe what I wanted precisely enough, learning to test systematically, and learning to iterate without fear.
The most important shift is mental: you are not a programmer who doesn't know enough yet. You are a product person who uses AI as a development partner. Those are different roles with different skills, and the second role is available to you right now.
I documented this entire workflow in Building Mobile Apps with Claude Code — a 186-page guide for non-technical founders and vibe-coders.
Available on Amazon (Kindle + Paperback) and Gumroad (PDF + EPUB, DRM-free).
Follow me for more on building with AI as a non-technical founder. Tag me when you ship your first app — I read everything.