How to Plan Your First App Before You Ask AI to Build It

The fastest way to build an app with AI feels like it should be: open the tool, type your idea, go. And for a quick experiment, it is. But for an app you actually want to use or launch, starting without a plan usually ends the same way — a pile of features that don't quite fit together, and an AI that keeps changing things you didn't ask it to.

Half an hour with a notebook changes that. Here's a simple way to plan, and a template to hand to your AI tool.

Step 1: write the problem in one sentence

Not the features — the problem. Who has it, and what does your app do about it?

Freelance photographers lose track of which clients have paid, so this app shows every client's invoices and marks the unpaid ones.

If you can't fit it in one sentence, the idea isn't clear yet. That's worth knowing before any code exists.

Step 2: list everything, then cut it down

Write down every feature you can imagine. Then split the list into two columns:

Version 1: the smallest set of features that solves the problem in your sentence.
Later: everything else.

Be ruthless. For the photographer app, version 1 might be: add a client, add an invoice with an amount and due date, mark it paid, see a list of unpaid invoices. Later: email reminders, PDF invoices, payments through the app, a mobile app, team accounts.

This first version is often called an MVP — a minimum viable product. A small app that works is worth far more than a big one that half works, and it's much easier for an AI to build correctly.

Step 3: describe who uses it

For each kind of user, one line:

Photographer (the only user in v1) — signs up, manages their own clients and invoices.

Later you might add "client — can view their own invoices." Writing roles down now forces the question that matters most for security: who is allowed to see what? (Answer for v1: each photographer sees only their own data.)

Step 4: walk through the main journeys

A user journey is the step-by-step path someone takes to get something done. Write the two or three most important ones:

Sign up: land on the homepage → sign up with email → arrive at an empty dashboard with an "Add client" button.
Record an invoice: open a client → "New invoice" → enter amount and due date → save → it appears as unpaid.
Get paid: open the unpaid list → click an invoice → "Mark as paid" → it disappears from the list.

Journeys become your checklist later: when the AI says "done," walk through each one yourself.

Step 5: sketch the data

What does the app need to remember? List the things and their details:

User: email, name
Client: name, email, belongs to a user
Invoice: amount, due date, paid (yes/no), belongs to a client

That's your database, roughly. It doesn't need to be perfect — but it helps the AI make sensible choices, and it makes relationships clear ("every invoice belongs to a client, every client belongs to a user"). (What Is a Database?)

Step 6: sketch the screens

A rough drawing of each screen — on paper, boxes and labels — is worth a hundred words of description. Photograph it and give it to the AI; most tools accept images. List the screens:

Homepage / sign-up
Dashboard (list of clients, unpaid total)
Client page (their invoices)
New invoice form
Unpaid invoices list

Step 7: decide the non-negotiables

A few decisions to make up front, rather than letting the AI make them silently:

Login: yes — use an established service, never a home-made system. (How to Add Login to an AI-Built App.)
Data privacy: each user sees only their own data.
Stack: popular, well-supported tools. (What Is a Tech Stack?)
Where it will live: your AI tool's hosting to start, or somewhere you control. (What Is Web Hosting?)
Money: if the app will take payments, say so now — it affects how it's built.

Step 8: turn it into a brief

Put it together and give it to your AI tool as the first message:

Build version 1 of this app.

Problem: [your one sentence]

Users: [roles, and who can see what]

Version 1 features (only these):
- ...

Not yet (don't build): [your "later" list]

User journeys:
1. ...

Data:
- User: ...
- Client: ...

Screens: [list, plus attached sketches]

Requirements:
- Use an established auth service; each user sees only their own data.
- Keep secret keys on the server.
- Use [stack] unless you have a strong reason not to — explain first.

Start by proposing a plan and the pages/tables you'll create. Don't write code until I approve the plan.

Listing what not to build is as important as what to build. It stops the AI from adding features you'll then have to debug.

Step 9: build in small steps

With the plan approved, build one journey at a time. After each, walk through it yourself, fix what's wrong, and save your work with git before moving on. (Git and GitHub for Beginners; How to Write Good Prompts for AI Coding Tools.)

Then — and only then — pick the next feature from your "later" list.

Keep the plan in the project

Save your brief as a file in the project (for example PLAN.md). Every new AI session can read it, and it keeps everyone — you and the AI — building the same app. For Claude Code, the most important rules also belong in CLAUDE.md. (How to Write a CLAUDE.md.)

EasySpawn gives your plan somewhere to become a real app: Claude Code building in a persistent workspace with a managed database, then deploying it to your own domain with SSL. See how it works for AI-built apps or join the waitlist.