Plan Your Web App

A web app has more moving parts than a website. More moving parts means more things that can go wrong and more ways for Claude to misunderstand what you want.

Ten minutes of planning before you open Claude Code prevents hours of fixing after.

This lesson gives you the planning framework. Fill it out before you write a single prompt.

The four things you need to define

Inputs

What information does the user give to the app?

List every field and be specific about the type. Is it a number, and if so what range and should it be a whole number or allow decimals? Is it text, and if so is it short or long, free form or from a list of options? Is it a choice made through a dropdown, radio buttons, or checkboxes? Or is it a date?

Example inputs for a Freelance Rate Calculator: annual income goal as a number in currency, working weeks per year as a number from 1 to 52, hours worked per week as a number from 1 to 60, and business expenses per year as a number in currency.

Example inputs for a Business Readiness Quiz: 8 multiple-choice questions each with 4 options and one answer selected per question.

Output

What does the app produce? What does the user see as a result?

Be specific here too. Is it a number and if so what label and units and how many decimal places? Is it a score and is it shown as a number, percentage, or label? Is it text such as a paragraph, a list, or a recommendation? Or is it a combination of several of these?

Example output for a Freelance Rate Calculator: recommended hourly rate in currency rounded to 2 decimal places, recommended daily rate based on an 8-hour day in currency, and annual income at that rate in currency.

Example output for a Business Readiness Quiz: total score out of 32, a result label based on score range such as Early Stage, Growth Ready, or Scale Ready, a 2 to 3 sentence description of what that result means, and 3 recommended next steps for that stage.

Behavior

Describe what happens at each step. Think like a user going through the app for the first time.

Write this as a simple numbered list.

Example behavior for a Freelance Rate Calculator:

One: user opens the app and sees a simple form with 4 labelled number fields. Two: user fills in their income goal, working weeks, hours per week, and expenses. Three: user clicks "Calculate My Rate." Four: the app calculates and displays hourly rate, daily rate, and annual income estimate below the form. Five: the results stay visible until the user changes a field or clicks Calculate again. Six: user can click "Reset" to clear all fields and start over.

Data storage

Does the app need to remember anything between page refreshes?

Use localStorage if it is a tracker app where the whole point is remembering data, if you want to save user inputs so they do not have to re-enter them next time, or if you want to save a score or progress across sessions.

Skip localStorage if it is a calculator where users fill it in fresh each time, if it is a generator with the same approach, or if it is a one-time assessment.

The planning template

Fill this in before writing your prompt:

APP NAME: [WHAT THE APP IS CALLED]
APP TYPE: [Calculator / Quiz / Tracker / Generator]
WHO USES IT: [ONE SENTENCE DESCRIPTION OF USER]
WHAT PROBLEM IT SOLVES: [ONE SENTENCE]
INPUTS:
- Field 1: [NAME] — [TYPE: number/text/dropdown/checkbox] — [ANY CONSTRAINTS]
- Field 2: [NAME] — [TYPE] — [CONSTRAINTS]
- Field 3: [NAME] — [TYPE] — [CONSTRAINTS]
[ADD MORE AS NEEDED]
OUTPUT:
- Result 1: [NAME] — [FORMAT: currency/number/label/text]
- Result 2: [NAME] — [FORMAT]
[ADD MORE AS NEEDED]

BEHAVIOR (step by step):

1. User opens the app and sees: [INITIAL STATE]
2. User [ACTION] and App [REACTION]
3. User clicks [MAIN BUTTON] and App [PRODUCES RESULT]
4. User sees: [RESULT STATE]
5. User can also: [SECONDARY ACTION IF ANY]
DATA STORAGE:
Save between sessions: [YES / NO]
If yes, what is saved: [LIST WHAT GETS SAVED]
ERROR HANDLING:
- If user submits with empty fields: [SHOW ERROR MESSAGE / BLOCK SUBMISSION]
- If user enters invalid data such as a negative number: [WHAT SHOULD HAPPEN]
- [ANY OTHER EDGE CASES SPECIFIC TO YOUR APP]

The minimum viable version rule

Whatever you planned above, cut it in half.

Build the simplest version that is still useful. If you planned 8 inputs, build with 4. If you planned 3 result types, build with 1. If you planned 6 quiz questions, build with 4.

You can always add more after the first version works. It is much harder to fix a complex app that does not work than to expand a simple app that does. Start small, get it working, then grow it.

Your action right now

Fill in the planning template for your app right now before moving to the next lesson.

Write the behavior section as a specific numbered list of steps. This becomes the exact blueprint for your master build prompt in the next lesson.