Building an app

With an AI app builder, you describe the app, watch it appear, and improve it one small step at a time. This page shows the whole loop, using a simple habit tracker as an example.

Start with a short spec

Think of ordering a custom cake. If you only say "a nice cake", you might get anything. If you say "chocolate, two layers, blue icing, for 10 people", you get what you wanted. A short spec is your cake order.

A spec is a short description of what the app should do. For a small app, half a page is plenty:

# Habit tracker

## Goal
Help one person track 3-5 small daily habits.

## Must have
- Add and delete a habit
- Check off a habit for today
- Show the streak (days in a row) for each habit

## Out of scope
- Login, reminders, payments

## Data
Save habits in the browser (local storage) so they stay after a refresh.

## Done when
I can add 3 habits, check them off, refresh, and still see them.

Let's break this down:

• Must have keeps the first version small
• Out of scope stops the AI from adding things you didn't ask for
• Data says where information is stored. Local storage is a small storage space inside the browser, so you don't need a database yet
• Done when gives you a clear test

For a fuller version, see Writing a PRD.

Write the first prompt

Your first message to the builder matters most. Use the Role, Context, Task, Constraints, Output pattern and paste in your spec:

Role: You are an expert front-end developer and designer.

Context: I'm a beginner building [your app idea].
Full spec below.
[paste spec.md]

Task: Build the first version with only the "Must have" features.

Constraints:
- No login, no backend, no database. Use browser local storage.
- Mobile-first, clean design.
- Keep the code simple and well organized.

Output: A working app with a live preview. Then list what you built
and suggest 3 small next steps.

In most builders, you paste this into the big chat box on the home page and press Enter. The first build can take a minute or two. The screen then splits into the chat on one side and the preview on the other. Layouts change over time, so look for those two parts.

Test the preview

Don't trust it just because it looks nice. Click around like a real user and run your "Done when" test. For the habit tracker, that means:

• Add three habits
• Check off two of them, then delete one
• Refresh the preview. Are your habits still there?
• Switch to the mobile preview. Is it easy to use?

Write down anything that is missing or broken. That list becomes your next prompts.

Iterate in small steps

Ask for one change at a time. Small requests are easier for the AI to get right, and easier for you to check.

Make the checkboxes bigger and easier to tap on a phone.
When an item is checked, show a soft green background and
a strikethrough on the name. Don't change anything else.

Notice "Don't change anything else". This simple guardrail stops the AI from rewriting parts that already work.

Fix bugs with debug prompts

Something will break at some point. That's normal. Describe the bug clearly:

Bug: [what you saw]
Example: When I check off a habit and refresh, the checkmark disappears.

Expected: [what should happen]

Steps to reproduce:
1. [first step]
2. [second step]
3. [third step]

Error message (if any): [paste it here]

Please find the cause, explain it in one sentence, and fix only that.

Let's break this down:

• Bug says what you saw
• Expected says what should happen
• Steps let the AI repeat the problem
• Fix only that keeps the change small

If the AI fails twice, use the version history to go back to the last working version and try a simpler request.

Common mistakes

• Wrong: "Make me a habit app." Right: a prompt with a role, the spec, clear limits, and the output you expect.
• Wrong: "Add dark mode, emojis, reminders, and login, and fix the chart." Right: one change per prompt.
• Wrong: "It's broken, fix it." Right: bug, expected result, steps, and any error message.
• Wrong: asking for five more fixes when the app keeps getting worse. Right: go back to the last working version.
• Wrong: only testing on a big screen. Right: try the mobile preview too.

What's next?

Your app works in the preview. Next, let's save it to GitHub and put it online in Publishing your app.