How to build an app with AI

This is the first decision that is hard to undo. For a first app, build a web app unless you have a specific reason to go native.

Ask the AI to argue for and against each option for your brief, then decide. Write the decision and the reason in CONTEXT.md.

Here is my app brief: [paste brief]. Should the first version be a web app
or a native mobile app? Argue both sides for my specific case, then recommend
one and name the framework you would use. Assume I have no coding experience.

A spec is a short document that lists what the app does precisely enough to build it. Ask the AI to write it from your brief, then correct it. It should contain:

• A list of screens, and what is on each one
• What data the app stores (for the habit tracker: habits, and which days each was completed)
• What happens on each button
• What is deliberately not in version one
• Every assumption the AI made

Turn this brief into a one-page spec for version one: list every screen and
what is on it, the data the app stores, what each button does, and what is
out of scope. At the end, list every assumption you made so I can correct them.
Keep version one as small as possible. Brief: [paste brief]

Read the assumptions carefully. This is where the AI decides things you did not say (for example, that the app needs user accounts, or that streaks reset at midnight UTC). Correct anything wrong, ask for a revised spec, and save the final version in CONTEXT.md.

Install Node.js, Git and Visual Studio Code if you have not already. Then open a terminal (on Mac: the Terminal app; on Windows: PowerShell) and check they work:

node --version
npm --version
git --version

Each command should print a version number. If one prints an error, paste the exact error into the AI and ask what to do; installation problems are the one area where AI answers are almost always right.

Create a folder for the app and turn it into a Git repository:

mkdir habit-streaks
cd habit-streaks
git init

Create the empty app using the framework's own starter command, not code the AI types out. Starters are maintained and tested; AI-typed project files often have outdated versions.

Web app (React with Vite):

npm create vite@latest . -- --template react
npm install
npm run dev

Mobile app (Expo):

npx create-expo-app@latest .
npx expo start

Open the address the terminal prints (for a web app, usually http://localhost:5173). You should see the framework's placeholder page. For Expo, install the Expo Go app on your phone and scan the QR code.

Now give the AI the layout of the project so it knows what exists. Ask it to explain the files:

I created a new [Vite React / Expo] project. Here is the file list: [paste the
output of `ls` or the folder tree]. Explain in plain language what each file
is for and which ones I will edit. Then tell me which file the first screen
should go in.

Commit: git add . && git commit -m "empty app runs".

This is the loop you will repeat for every screen and every feature. Doing it in small pieces is what makes AI coding work; asking for the whole app at once is what makes it fail.

1. Describe one screen. Paste the spec section for that screen, and the current contents of the file it goes in.
2. Ask for the code and an explanation. "Write the code for this screen, then explain what each part does in two or three sentences."
3. Put the code in the file and run it. Look at it in the browser or on the phone. Click everything.
4. Report back exactly what happened. If there is an error, paste it word for word. If something looks wrong, describe what you see and what you expected.
5. Repeat until the screen works, then commit.

Build the habit list screen from this spec: [paste spec section]. It goes in
src/App.jsx, which currently contains: [paste file]. Use plain, simple code
with no extra libraries. After the code, explain what each part does.

Start with the screen the person sees first. For the habit tracker: the list of habits with a tick button. Then add habits. Then the streak count. Each is one pass through the loop.

Your app needs to remember things between opens. Use the simplest option that works, in this order:

Ask the AI to design the data first, then to add the storage code:

Based on the spec, what data does this app store, and in what shape? Show it
as a simple example. Then add code to save it to [localStorage / Supabase] and
load it when the app opens. Explain how I can check the saved data myself.

Many first apps do not need either. If yours does, use a hosted service and never handle passwords or card numbers in your own code.

• Sign-in: Supabase Auth, Firebase Auth or Clerk. All handle passwords, email links and "sign in with Google/Apple" for you.
• Payments: Stripe for web apps. For mobile apps sold through the stores, Apple and Google require their own in-app purchase systems for digital goods; RevenueCat makes that manageable.

Add sign-in with [Supabase Auth] to this app. Show me exactly which settings to
create in the Supabase dashboard, then the code. Do not store passwords
anywhere in my code. Explain what happens if someone is not signed in.

Code that runs is not code that works. Before publishing, do three kinds of testing.

Use it like a stranger would

Open the app fresh, with no data. Add nothing and look at every screen: are the empty states sensible? Then add too much: 50 habits, a name with emoji, a very long name. Turn off the internet. Rotate the phone. Close and reopen. Write down everything odd.

Have the code reviewed by an AI, ideally a different one

An assistant reviewing its own code tends to approve it. If you can, paste the code into a different AI and ask for problems. If you only have one, start a fresh conversation so it has no memory of writing it.

Review this code as a senior developer who did not write it. List bugs,
security problems and things that will break for real users, ordered by
severity. For each, show the exact fix. Be critical; do not praise the code.
[paste file]

Check the usual suspects

• Time zones and midnight (see step 7)
• What happens when storage is empty, full or corrupted
• Double taps: pressing a button twice quickly
• Data from the previous version of the app after an update
• On mobile: older phones, small screens, dark mode, notifications denied

Fix what you found using the loop in step 6. Commit.

Web app

Push your code to GitHub, then connect the repository to a hosting service. Vercel, Netlify and Cloudflare Pages all do this for free and rebuild the site every time you push a change.

git remote add origin https://github.com/YOUR-NAME/habit-streaks.git
git push -u origin main

Then, in the hosting service's dashboard: New project, import from GitHub, choose the repository, deploy. You get a public address within minutes. Add your own domain later if you want one.

Mobile app

With Expo, the EAS Build service produces the files the stores need. You will also need an Apple Developer account (paid yearly) and a Google Play developer account (one-time fee). Store review takes from a day to a week and commonly rejects apps for missing privacy policies, crashes on launch, and screenshots that do not match the app.

Publishing checklist

Ask the AI to produce this for your specific app and platform, then work through it:

• App name, icon, and screenshots at the sizes the store requires
• A privacy policy page (required by both stores and by most hosting terms if you collect any data)
• Error reporting, so you learn about crashes before users tell you (Sentry has a free tier)
• Basic analytics, so you know whether anyone is using it
• A support email address
• For stores: the review notes, including a test account if sign-in is required

Whether your app lives in a store or on the web, people decide in a few seconds from a title, a sentence and a screenshot. AI is very good at drafting these, and very bad at knowing your user. You supply the user; it supplies the words.

Start with a positioning sentence

One sentence in the form: [App] helps [who] do [what] without [the annoying thing]. For the example: "Habit Streaks helps busy people keep one or two daily habits without losing their streak to a time-zone glitch." Everything else is built from this.

Here is my positioning sentence: [sentence]. Write five alternative versions,
each emphasising a different benefit. Then tell me which one you would put
on a billboard and why. Avoid hype words like "revolutionary" or "seamless".

App store listing

Store listings are searched like a search engine. Ask the AI for the words people would actually type when looking for an app like yours, then use them in the title and the first two lines of the description, where they matter most.

Write an App Store and Google Play listing for this app: [positioning
sentence and feature list]. Include: a title under 30 characters, a subtitle,
the first two lines of the description (these are the only ones people see
before tapping "more"), a full description, and 20 search keywords people
would actually type. Plain language, no exclamation marks.

Landing page

A web app needs a landing page; a mobile app benefits from one too, because it is where you send people from social posts and emails. A good first landing page has five parts: headline, one sentence under it, a screenshot or short video, three short benefits, and one button. Ask for exactly that, then have it built with the same screen-by-screen loop from step 6.

Write the copy for a one-screen landing page: headline (under 10 words),
one supporting sentence, three benefits of one line each, and the button
text. The reader is [describe your user]. Then write the page as a simple
HTML file I can publish, with the copy in place and a spot for a screenshot.

The first fifty users almost never come from ads. They come from places where your users already talk to each other, and from you personally asking. AI helps you find those places and write the messages; it cannot do the asking for you.

Map where your users are

My app is for [describe user]. List 20 specific places online where these
people already gather: subreddits, Facebook groups, Discord servers,
forums, newsletters, YouTube channels, podcasts. For each, say what kind of
post would be welcome there and what would get me banned.

Check each one yourself. Read the rules. Spend a week being useful there before you mention your app. Communities can tell when someone arrives only to promote.

Write the launch messages

You need a handful of pieces: a short post for communities, a launch post for a site like Product Hunt if it fits, a direct message to people you know who match the user, and a one-line reply you can use when someone asks "what do you do?". Ask for all of them at once, in your voice.

Here is my positioning sentence and my landing page copy: [paste]. Write:
1) a 120-word community post that leads with the problem, not the app;
2) a Product Hunt style launch description; 3) a personal message to a
friend who fits the user, asking them to try it and tell me honestly what
is wrong with it; 4) a one-line answer to "what are you working on?".
Write the way I write: [paste two or three sentences you wrote yourself].

Ask for feedback, not for praise

Every first user is worth more as a source of feedback than as a download. Ask each one three questions: what did you expect it to do, what confused you, and would you miss it if it disappeared. Put the answers in a file; you will use them in step 15.

Once the first users are in, marketing becomes a routine rather than a launch. AI makes the routine affordable for one person. Pick two of these channels, not all of them.

Articles people search for

Ask the AI for the twenty questions your users type into a search engine that your app answers. Write one useful article a week answering one of them, with the AI drafting and you adding what only you know. Put it on your landing page's domain. This compounds slowly and is the cheapest long-term channel.

Social posts

Give the AI one real thing that happened this week (a user story, a bug you fixed, a number) and ask for three short posts about it in your voice. Post the one you would actually say out loud. Generic AI posts about "productivity tips" get ignored.

Onboarding emails

If people give you an email address, send three short emails in the first week: how to get the first win, the one feature people miss, and a question asking what they think. Ask the AI to draft the sequence from your spec, then cut every sentence that sounds like marketing.

Small paid tests

Only after the free channels show that people who arrive actually stay. Ask the AI for five ad variations built on your positioning sentence, run them with a small budget, and let the numbers pick the winner.

My app: [positioning sentence]. List 20 questions my users would type into
a search engine that my app helps answer. Rank them by how likely someone
asking is to want the app. For the top one, outline a 700-word article that
answers it properly, and tell me where I should add my own experience.

Read the numbers with AI

Once a month, export whatever your analytics and store dashboards give you (installs, sign-ups, people still active after a week, cancellations) and paste the table in. Ask what changed, what it suggests, and what one thing to try next. An AI is a patient analyst for numbers you do not have time to study.

Support is where small apps quietly lose users: a question goes unanswered for a week and the person is gone. AI lets one person answer quickly and kindly without it taking over the day.

Build a short help document

Ask the AI to turn your spec and your feedback file into a plain-language FAQ: the ten questions people actually ask, with clear answers. Put it on your landing page and in the app. Half of support requests stop arriving once this exists.

From my spec and this list of user questions [paste], write a help page with
the ten most common questions and short, friendly answers. Where an answer
depends on something I have not told you, say so instead of guessing.

Draft replies, then send them yourself

Paste each support email into the AI along with the help document and ask for a reply in your voice. Read it, fix anything wrong, and send it from your own address. Keep the human in the loop: users forgive slow, they do not forgive wrong.

Here is a support email: [paste]. Here is my help document: [paste]. Draft a
reply that answers the question directly in the first sentence, is warm
without being chatty, and admits it if this is a bug on my side. If the
answer is not in the help document, tell me what I need to find out first.

Feed support back into the product

Every support question is a design flaw or a missing sentence in the app. Add each one to the feedback file from step 15. When the same question arrives three times, the fix belongs in the app, not in another reply.