How to Build an App With Claude Code as a Non-Developer: A Safe 7-Step Method

A first project that is too big rarely gets finished, so cut it to what you can build in a week. Write your idea in a few lines: who uses it, and the one job it does for them. Then sort every feature into four boxes:

Build only Must and Money in week one. In the Northwind cut, version one stores no personal data and takes no payments. That single choice removes most of the serious risks. Add logins, payments or customer details only after the first version works and someone has reviewed it.

A spec (some people call it a PRD) tells the agent what to build. The most important part is the list of checks that prove the app is done. Each check must be something you can test by hand in under a minute.

SPEC: NORTHWIND PRICE ESTIMATOR (v1)

Goal: office staff price a cleaning job in under 30 seconds.
User: office staff, on a laptop or phone. No login.

Must:
- Choose number of bedrooms (1 to 5) and bathrooms (1 to 4).
- Tick extras: oven, windows, fridge.
- See the total price, updated as you change choices.
Prices (example): base visit $60, each bedroom $20, each bathroom $15,
oven $25, windows $30, fridge $15.

Never in v1: customer names, emails, phone numbers, payments,
logins, a database.

Done when ALL of these pass:
1. 2 bedrooms + 1 bathroom, no extras shows $115.
2. 3 bedrooms + 2 bathrooms + oven shows $175.
3. Changing any choice updates the price at once.
4. The page works on a phone screen without sideways scrolling.
5. No price appears anywhere except the prices listed above.

The prices here are made up. Put in your own price list, then work out the expected totals yourself, with a calculator, before the build. If the app shows a different number, the app is wrong, not your sum.

Install it with the official command for your system (setup). There is also a desktop app if you prefer not to use a terminal.

# macOS, Linux or WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

Open a new terminal window and check that it worked:

claude --version

A version number means it worked. Some older guides tell you to install with npm and an old Node.js version. Follow the official page instead, because it changes.

Now make one folder for the project and start Claude Code there:

mkdir northwind-estimator
cd northwind-estimator
claude

The first time, Claude Code opens a browser window to log in. Before you type anything else, look at the mode label under the prompt. Newer versions start in auto mode, where Claude Code approves many actions without asking you. For your first projects, press Shift+Tab until the label says Manual (the docs also call it default). In Manual mode it asks before most edits and commands, so you see each action (permission modes). Now ask: "Set up git in this folder. If git is not installed, tell me how to install it on my system." Git keeps a saved history of every working version, so you can always go back. Then copy your spec into a file in the folder called SPEC.md.

Before your first commit, hide the secret file. Ask Claude Code: "Create a .gitignore file that lists .env, and show me the file." Check that the file exists. Rules in the instructions file (next step) are guidance the agent usually follows, not a lock, so always check this yourself.

Claude Code reads a file called CLAUDE.md at the start of every session. Put your project rules there. The command /init creates a starter version, and the docs suggest keeping each file under 200 lines, because longer files are followed less well (Claude Code memory docs). Other coding agents use a similar file, often called AGENTS.md.

Here is a starter for a non-developer. Paste it in and edit the first section.

# Project: Northwind price estimator

## About me
I am not a developer. Explain every step in plain English,
in 3 sentences or fewer, before you do it.

## The spec
SPEC.md is the source of truth. Do not add features that are
not in it. If you think something is missing, ask me.

## How we work
- One small task at a time. After each task, tell me exactly
  how to test it by hand, then stop and wait.
- Prefer the simplest setup that works. Ask before adding any
  new tool or library.
- Never delete files or folders without asking me first.

## Safety rules
- Never put passwords or API keys in code files.
  Keep them in a .env file, and make sure .gitignore lists
  .env BEFORE the first commit.
- No personal data and no payments in v1.
- If a fix fails twice, stop and explain what you think is
  wrong, instead of trying a third guess.

The last rule saves hours. An agent that keeps guessing can make a small problem bigger.

Use the same loop for every feature. One loop should take 10 to 30 minutes.

1. Plan first: switch to plan mode (press Shift+Tab until it shows plan mode). In plan mode, Claude Code cannot edit files until you approve a plan (permission modes). Ask: "Read SPEC.md. Propose a plan for the first Must item only. Keep it simple."
2. Read the plan: if you don't understand a step, ask. If it adds things you didn't ask for, say no.
3. Build: approve the plan. Stay in Manual mode so you see each edit and command before it runs. Do not use the mode that skips all permission checks. The docs say it is for isolated containers and virtual machines only (permission modes).
4. Test it yourself: open the app and try the done-checks for this feature. Do not accept "it should work now". Click it.
5. Save a working version: when it works, ask: "Commit this to git with a short message."

If a step goes wrong, type /rewind, or press Esc twice while the prompt box is empty, to go back to an earlier point in the session. But know its limits: rewind does not undo file changes made by terminal commands, and the docs say checkpoints are not a replacement for version control (checkpointing). Your git commits are your real safety net.

When something breaks, be specific. Not "it's broken", but: "When I pick 3 bedrooms and tick oven, the price shows [wrong number]. The spec says [right number]. Find the cause and explain it before you change anything."

When every Must item works, run a full check in a fresh session, so the reviewer doesn't defend its own work. Start a new Claude Code session in the same folder, press Shift+Tab until it shows plan mode (so it can't edit files), and paste:

You are reviewing this project before it is shown to anyone.
Read SPEC.md and all code files. Do not change anything.
Report:
1. Each done-check in SPEC.md: pass, fail, or cannot tell.
   Say how you checked.
2. Any feature in the code that is not in the spec.
3. Any password, key, token or personal data in the code,
   and whether .env is listed in .gitignore.
4. Anything that would break on a phone screen.
5. The 3 biggest risks, in simple words.

Then do your own check by hand:

• Run every done-check yourself, on a laptop and on a phone.
• Try silly inputs: tick everything, untick everything, reload the page.
• Ask a colleague to use it without help, and watch where they get stuck.

Fix what fails, commit, and check again.

To share the app, you need to put it online, which is called "deploying". Ask Claude Code to explain your options and what each costs, and pick one with a free tier for a first version. Before you deploy:

• Keep the code private. If you store it on a code-hosting site, make the repository private.
• Check for secrets one last time. Ask: "Search the whole project, including the git history, for passwords, keys or tokens." A key that reached git history stays there even after you delete it from the file. If one did, treat it as leaked: cancel it and make a new one.
• Start with a small group. Share the link with your own team first. Fix what they find.

When to bring in a developer

Pay for a review by an experienced developer before any of these:

• Real users log in.
• The app takes payments.
• The app stores personal data, such as names, emails, phone numbers or addresses.
• The app handles health or legal information.
• The same problem survives three focused attempts to fix it.