How to build your first app with AI

You can get a working app out of a coding agent in an afternoon. Getting one that people use, that runs on their phones and that the app stores accept takes the same afternoon plus a plan. This is the plan, in the order the work happens.

It assumes you will use a coding agent such as Claude Code or Codex, and that you want a mobile app on iPhone and Android. Most of it applies to a web app too.

1. Find what people already pay for

Before you decide what to build, look at what people are already paying for. TrustMRR is a database of small apps and startups whose revenue is verified through the payment providers they use, such as Stripe, RevenueCat and the App Store. ^[1] Browse it for an hour. You are looking for apps with real money coming in that you could do better, or do for a group of people the current apps ignore.

A man lying on a floor covered in banknotes, making a snow angel in the cash (GIF on Tenor)

Verified revenue is the best market research there is.

An idea nobody pays for yet can still be a good one. It is simply a much harder first app, because you will be proving the market at the same time as learning to build.

2. Study the competition and pick your angle

Ask your agent to find your main competitor apps, then read their features and their reviews. The one-star reviews tell you the promise each app breaks, in the users’ own words. The five-star reviews tell you what people actually pay for. Between them you will find the angle that makes your app different: the thing the others do badly, or the group of users they forgot.

Three identical Spider-Men pointing at each other (GIF on Tenor)

Three apps with the same features and the same angle. Yours needs to be the one that isn’t pointing.

Write the angle down in one sentence. Everything from here on is checked against it.

3. Make a branding pack

Next, decide what the app looks and sounds like, before a single screen exists. The agent can draft all of this from a short brief, and you edit until it feels right. A branding pack covers:

Six decisions about how the app looks and sounds, taken once and written down so every screen follows them. The design system can be borrowed from a UI library.

Colours. Take them from a UI library’s palette; there is a short guide to choosing colours for an app on this site.
Logo. A simple mark the agent can draw in code, so it scales to an app icon and a favicon.
Fonts. One for headings, one for body text, both free to use.
Tone of voice. How the app talks: the words on its buttons, its error messages, its empty screens.
Visual identity. The feel: spacing, corners, illustration style, how much motion.
A design system. The set of components every screen is built from. You can use an existing one, and for a first app you should: a design system such as the one that comes with your UI library gives the agent consistent parts to build with.

Save the pack in your project. The agent reads it on every feature, so the fiftieth screen matches the first.

4. List every feature, then split them

Now list every feature you want in the app. All of them, including the ones you suspect are too much. Then split the list into two groups: what goes into the MVP, the smallest version that does the one job your angle promises, and what can wait.

The same list sorted once. The left column is enough to prove the angle; everything on the right waits for a real user to ask for it.

Be strict here. Each feature in the MVP column is screens to design, code to build, tests to write and things that can go wrong in review. A first release with five features that work beats one with fifteen that nearly do.

5. Turn each MVP feature into a user journey

Take each MVP feature and write it as a user journey: the exact sequence of screens a user moves through to get the job done, with what is on each screen and what happens when they tap. “A client buys a T-shirt” becomes browse, open the item, add to basket, check out, done.

One feature, written as the screens a user moves through to get the job done. The agent builds exactly this, and later it becomes the test that proves the feature works.

Two sites are worth having open while you do this. Mobbin is a searchable library of real screens and flows from shipped apps: a hundred ways other apps handle a sign-up or a checkout, before you design yours. Dribbble is for the look rather than the flow. Borrow patterns freely; users already know them.

The journeys are the heart of your plan. The agent builds exactly what they describe, and later they become the tests that prove each feature works.

6. Choose your stack

The stack is the set of tools the app is built on. Ask your agent to recommend one for your app, but here is the one I use for most projects, with what each part does:

React with Expo builds the app itself, one codebase for both iPhone and Android.
Supabase is the backend: the database, user accounts and sign-in, and the code that runs on a server.
RevenueCat handles subscriptions and one-off purchases across both stores.
PostHog is analytics: which screens people use, where they drop off.
Sentry collects crash reports from real users’ phones, with the line of code that caused each one.

At the time of writing each of these has a free tier big enough for a first app, and each has an official connector that lets your agent work with it directly.

7. Create a GitHub account

GitHub stores your code online and keeps every version of it, so a change that breaks something can be undone and your work survives your laptop. Create a free account, and have the agent save its work there after each feature. The stores and the build services in the next steps all connect to it.

8. Open your store accounts now

Do this before you build, not after, because both stores take time to approve a new account and one of them has a waiting period that catches first-timers out.

Apple Developer Program: US$99 a year, or the local equivalent. ^[2] This gets you App Store Connect, where you submit the app, and TestFlight, where you test it.
Google Play Console: a US$25 one-off registration fee. ^[3]

Here is the rule that bites. At the time of writing, a personal Google Play developer account created after 13 November 2023 must run a closed test with at least 12 testers who stay opted in for 14 days in a row before it can apply to publish to the public. ^[4] Twelve friends and a fortnight is fine, but only if you know about it in advance. Open the account now, and line up the testers while you build.

9. Build the MVP with a docs folder

Now the agent builds. Give it one user journey at a time, check the result on your own phone, then give it the next. Do not ask for the whole app in one prompt.

What keeps the build on track is a docs folder in the project: the branding pack, the feature list, the user journeys and the decisions you have made, in plain files the agent reads before every piece of work. Without it, every new conversation starts from nothing and the agent reinvents what you decided last week.

yourapp/
  AGENTS.md            the instruction file the agent reads first
  docs/
    README.md          a map of the rest
    architecture/      how the app is put together
    branding/          the branding pack
    epics/             each feature, with its user journeys
    handbooks/         how things are done in this project
    research/          what you learned about users and competitors
    releases/          what shipped, and when
    legal/             privacy and terms, drafted from what the app collects

The layout matters less than the habit. A short instruction file at the project root that says who you are and where things are, then a docs folder with a file per subject. Ask the agent to set it up on day one and to record each decision in it as you go.

10. Have the agent write tests as it goes

Every feature you add is a chance to break one that worked yesterday. The protection is automated tests: small programs the agent writes alongside each feature that check it still does what the user journey says, and that run every time the code changes.

Many small checks at the bottom, a few whole-journey checks at the top. Ask the agent for this shape, and for the rule that a feature is not finished until its tests pass.

Ask for the shape of the pyramid: lots of unit tests that each check one small piece, fewer integration tests that check the pieces work together, and a handful of end-to-end tests that walk a whole user journey the way a person would. Tell the agent that a feature is not finished until its tests pass, and that a change which breaks an old test is not allowed to land.

11. Test real builds on real phones

The app that runs in the phone simulator on your laptop is not the app your users will get. Before anyone else sees it, install a real build on a real phone and use it the way they would.

On iPhone that means TestFlight, Apple’s system for sending test builds to people you invite; it is part of your developer account. ^[5] On Android it means an internal testing release in the Play Console, which goes out to up to 100 testers you name. ^[6] Both services need the store accounts from step 8, which is one more reason to open them early.

12. Buy a domain and build five pages

Your app needs a website, and not mainly for marketing. Both stores ask for a privacy policy they can link to, and both expect a support contact and a way for users to ask for their account and data to be deleted. Buy a domain, have the agent build a small site, and make sure it has these five pages: Home, Privacy, Terms, Support and Delete your account. Have the agent draft the privacy and terms pages from what the app actually collects, then read them yourself before they go live.

The stores link to the privacy policy, want a support contact and expect a way for users to ask for their account and data to be deleted. The home page is for people; the other four are for the reviewers.

13. Send it in for review

With the tests passing, the build tried on real phones and the website live, submit the app to both stores. Fill in the listing properly: screenshots from the real app, a description that says what it does for the user, and the links to the pages from step 12. Apple and Google each review the app and decide whether it goes live; a first submission often comes back with a question or two, and you fix and resubmit.

Someone crossing their fingers and holding them up (GIF on Tenor)

Submitted. Apple and Google decide the rest.

14. While you wait, set up a morning routine

Review takes anywhere from a day to a week or so. Use it to set up the thing that will keep the app healthy once people are using it: a scheduled routine that runs each morning, reads the new crash reports from Sentry, works out what caused each one and opens a proposed fix for you to review. You still decide what ships. The routine means you find out about a crash from a report on your desk rather than from a one-star review.

Claude Code can run a routine like this on a schedule, which is how mine works, and the connector from step 6 gives it the crash reports to read.

15. You have your first app

A man getting a face full of confetti and shouting yeah (GIF on Tenor)

Approved. It’s in the stores.

When the approvals come through, the app is live on both stores with a website, tests, crash reporting and analytics behind it. That is a real first app, and the plan you wrote in steps 3 to 5 is now the plan for the second release: the features that waited, in the order users ask for them.

If you would rather watch all of this happen on a real project, Building RepGarden follows an app being built this way, decision by decision.

Sources

TrustMRR. The site describes itself as “the database of verified startup revenues” and says all revenue is verified through supported payment providers including Stripe, RevenueCat, Superwall, the App Store and Creem. trustmrr.com.
Apple — Apple Developer Program, what’s included. “The Apple Developer Program is 99 USD per membership year, or in local currency where available.” Some nonprofits, schools and government bodies can ask for the fee to be waived. developer.apple.com.
Google — How to use the Play Console. “There is a US$25 one-time registration fee.” The same page says personal accounts must complete app testing requirements before publishing. support.google.com.
Google — App testing requirements for new personal developer accounts. Personal accounts created after 13 November 2023 “must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days” before applying for production access. Checked on 31 October 2026; Google changes these rules, so read the current page. support.google.com.
Apple — TestFlight. “TestFlight makes it easy for testers to give feedback on your apps, games, and App Clips across Apple platforms before you publish.” Up to 10,000 external testers can be invited. developer.apple.com.
Google — Set up an open, closed, or internal test. An internal testing release goes to up to 100 testers. support.google.com.

On this page