Planning a bigger app

A small app can be built from one good prompt. A bigger app cannot. Before you ask an AI agent to write code, spend a little time on a plan.

Why plan first?

Nobody builds a house by stacking bricks and hoping. They start with a blueprint. Your plan is the blueprint your AI coding agent follows in every session.

A good plan for a bigger app covers four things:

• Pages — the screens, so you know what the app looks like
• Data — what the app remembers, so the database makes sense from day one
• User roles — who can do what
• Build order — small steps, each one testable

Without a plan, the agent guesses. And every session guesses a little differently.

List the pages

Start with the screens. Each page has a path, the part of the web address after the domain, like /recipes. Next to each page, note who can see it.

For example, imagine a recipe app where people save and share recipes:

The [slug] part means "fill in a name here". Each recipe gets its own address, like /recipes/lemon-pasta.

Sketch the data model

A data model is the list of things your app remembers, and how they connect. Think of the labeled drawers in a filing cabinet. Each drawer becomes a table in your database.

The recipe app might need three tables:

• recipes — title, slug, ingredients, steps, photo, and who wrote it
• profiles — extra info about each user: name and role
• saved_recipes — which user saved which recipe

You don't need the exact columns yet. Names and a one-line purpose for each table are enough.

Decide the user roles

A role is a label that decides what someone can do. Most apps need two or three:

• Visitor — not logged in, can browse public pages
• User — logged in, can manage their own data
• Admin — runs the app, can manage everyone's content

Write the roles into your plan now. Later they become login rules and database rules.

Choose a build order

Build one layer at a time. Each layer should work, and get tested and committed, before the next one starts.

Pages come first because you can see them. Once they look right, you swap the sample data for a real database.

Write the plan with plan mode

You don't have to write the plan alone. Make a project folder with a docs folder inside, start your coding agent there, and switch to plan mode (in Claude Code, press Shift+Tab until it says plan mode). Then send a prompt like this:

You are helping a beginner plan a web app.
App idea: [your app idea, in 2-3 sentences]
Users: [who will use it]

Write a plan in docs/PRD.md with these sections:
1. Goal and target user
2. Features (must-have first, nice-to-have later)
3. Pages, with URL paths and who can see each one
4. Data model: table names and one sentence about each
5. User roles and what each role can do
6. Build order in small, testable steps
7. Out of scope for now

Show me the plan first. Don't create files until I approve.

Let's break this down:

• The placeholders in brackets are where your own idea goes
• The numbered sections match the four parts of a good plan
• "Out of scope" stops the app from growing forever
• "Show me the plan first" gives you a chance to fix it before anything is written

Read the plan. Ask for changes until you're happy. Then leave plan mode and say "Looks good, write the file." Finally, ask the agent to create a short CLAUDE.md from the plan, and a .gitignore that lists .env, .env.local, and node_modules.

Common mistakes

• Skipping the plan. The agent fills the gaps with guesses, and the app drifts.
• Planning too much detail. You don't need exact colors or every button. Pages, data, roles, and order are enough.
• Building everything at once. One step at a time, tested and committed, is faster in the end.
• Changing table names halfway. If the data model must change, update the plan and CLAUDE.md first.

What's next?

With a plan in place, you can start building. Next, let's create the pages and layout people will actually see.