How to Turn an App Idea into a Working Prototype with Claude Code

Most app ideas die in a notes file. The ones that survive usually get built badly, because the first session with an AI coding tool turns into a pile of half features. Claude Code can take you from idea to something you can click through in a weekend, but only if you run it like a small project instead of a wish.

This is the order I follow when I start a new app. It is simple, and every step exists because skipping it costs more time later.

Write the idea down before you open the terminal

Claude is very good at building what you describe. It cannot guess what you meant. So start with one paragraph in plain words: who the app is for, the one job it does, and what "done" looks like for a first version.

Keep the first version small. One user type, one core flow, one screen that proves the idea works. Accounts, payments, admin panels and settings pages can all wait until someone actually uses the thing.

Let Claude interview you and write a spec

Create an empty folder, open it in the terminal and start claude. If you have not installed it yet, the setup page has the current install command for your system.

Then press Shift+Tab until the status bar shows plan mode. In plan mode Claude reads and asks questions without touching files, which is exactly what you want at this stage. Paste something like this:

I want to build [one paragraph about the idea].
Interview me before writing any code. Ask about the users, the core flow,
edge cases, data I need to store, and what I want to leave out of version one.
Ask one topic at a time. When we are done, write SPEC.md with:
the problem, the core flow step by step, the data model, the screens,
what is out of scope, and how we will know version one works.

Plan mode will not write files, so when the interview is done, press Shift+Tab again to leave it and let Claude save the spec. Answer honestly along the way, including "I don't know yet". The questions are often more useful than the spec, because they expose the parts of the idea you have not thought through. Anthropic's own best practices recommend this interview step for larger features.

Research in parallel, then decide the stack

Before building, ask Claude to check the ground. Claude Code can run subagents, each in its own context, so a few questions can be researched at the same time without flooding your main conversation.

Use subagents in parallel to research:
1. Existing apps that solve this problem and what users complain about in them
2. The simplest stack that fits SPEC.md for a solo builder
3. Any API or service we depend on, its limits and pricing page
Then summarize in RESEARCH.md and recommend one stack with reasons.

Read the recommendation and push back if it is heavier than you need. For most first versions, fewer moving parts wins. You can always add a service later. Removing one is painful.

Give the project a memory

Run /init once there is a little structure. It creates a CLAUDE.md file that Claude reads at the start of every session. Keep it short and specific. The memory docs explain how it loads.

# Project
Habit tracker for freelancers. Spec lives in SPEC.md.

# Stack
[framework], [database], [hosting]

# How we work
- Build one feature at a time, in the order of the plan
- After each feature, run the checks below and show me the result
- Never add a dependency without asking

# Checks
- npm run lint
- npm run typecheck
- npm test

This file is where your standards live. When Claude does something you do not like twice, add a line here instead of repeating yourself in chat.

Build in vertical slices

Ask for a numbered plan from the spec, then build one slice at a time. A slice goes all the way through: the data, the logic, the screen, and a test. "The whole backend first" sounds organized and usually means you see nothing working for days.

Read SPEC.md and write PLAN.md: numbered slices, each one small enough
to finish and test on its own, each one usable by a person when done.
Then build slice 1 only. When it works, run the checks from CLAUDE.md,
show me the output, and stop.

The "stop" matters. You review, you click through it, you commit it with git. Then you move to slice 2. Small commits give you a clean place to go back to when a later slice goes wrong.

Make Claude prove its work

The biggest quality jump comes from giving Claude a way to check itself. Tests, a type checker, a linter and a production build all return a signal it can read and act on. For interfaces, a screenshot is the check. With the Chrome integration Claude can open your app, look at it, and fix what does not match.

Open the app in the browser, go through the core flow from SPEC.md
as a new user, take screenshots at each step, and list anything
that is broken, confusing or ugly. Fix the list, then repeat once.

Ask for evidence. "All tests pass" is a claim. The test output is proof. If you want the checks enforced every time, hooks can run commands automatically at points in the session, such as when Claude finishes a turn.

Payments and accounts come last

When the core flow works and a real person has tried it, add accounts, then payments. Claude can write the integration code, but the accounts are yours. With Stripe, for example, you start with test mode keys and only switch to live keys after you have verified the business details they ask for.

Keep keys in environment variables and out of the repository. Tell Claude that explicitly, and check the diff before every commit that touches configuration.

What a weekend actually gets you

A focused weekend gets you a working prototype you can demo and put in front of five users. That is a lot. It is also different from a product people pay for. Before you charge money, review the security of anything that handles logins and payments, test the flows that fail (wrong card, lost connection, empty states), and deploy somewhere you can monitor.

Start tonight with the interview step only. Write the paragraph, let Claude question you, and read the spec it produces. If the spec still excites you the next morning, build slice 1.