Claude Code Tutorial: Build Your First App, Step by Step

Claude Code is Anthropic's coding agent. Unlike a chatbot that hands you code to paste, it works directly in your project: it reads files, edits them, runs commands like your tests, and uses git. You describe the outcome, and it does the steps, asking for permission along the way.

It started as a terminal tool, and that's what this tutorial uses. It also runs as a desktop app, in VS Code and JetBrains, and on the web at claude.ai/code. The concepts carry over.

What you need:

• A computer that can run it: macOS 13+, Windows 10 (1809+), Ubuntu 20.04+, Debian 10+, or Alpine 3.19+, with 4 GB of RAM and an internet connection.
• A terminal. Never used one? Anthropic's terminal guide shows how to open one and paste a command.
• A paid account. The options, from Anthropic's pricing page on November 5, 2026:
  • Pro: $20 a month, or $17 a month billed yearly. Enough to learn on and build small projects.
  • Max and Ultra: higher-usage plans for daily heavy use. Check claude.com/pricing for current limits.
  • Team: $25 per seat a month ($20 billed yearly), or $125 for a Premium seat with 5x the usage.
  • Claude Console: pay per token with pre-paid API credits, no subscription.

Start with Pro. Subscriptions have usage limits that reset every five hours and every week, and you'll find out quickly whether you hit them. For this tutorial you'll also want git and Node.js 20 or later, which the project uses to run its tests.

The native installer is what Anthropic recommends, because it keeps itself updated in the background. It shows no progress while it downloads, so give it a minute. When it finishes, open a new terminal window and check the version. If your shell says claude isn't found, the install folder isn't on your PATH yet; Anthropic's troubleshooting page covers the fix.

On native Windows, also install Git for Windows so Claude Code can use Bash. Without it, Claude Code falls back to PowerShell. If you use WSL, run the Linux command inside WSL instead.

Then start Claude Code in any folder. The first time, it asks you to log in and opens your browser. Pick your Claude subscription or Console account, approve, and you're back in the terminal with a prompt. Your credentials are saved, so you only do this once. To switch accounts later, type /login in a session.

Before you build anything, spend five minutes asking questions about code that already exists. It's the fastest way to see how Claude Code works, and nothing can break, because reading files never needs your permission.

Open any project you have, or clone a small open-source one, and start claude inside it. You don't need to paste files or explain the layout: Claude Code reads what it needs. Try the prompts below one at a time and watch the tool calls it makes as it works. You'll see it search, open files, and sometimes run commands to understand the project.

Three things worth trying in this first session:

• Point at a file by typing @ and the path, which adds that file to your message. Useful when you already know where the answer is.
• Run a command yourself by starting a line with !, like !git log --oneline -5. Claude sees the output too.
• Ask Claude about Claude Code. "How do I resume a session?" works, because it can answer questions about its own features.

Type /exit (or press Ctrl+D twice) when you're done. claude -c picks up the last conversation in that folder later.

Now the real part of this Claude Code tutorial for beginners: you'll build a tip splitter, a one-page web app that takes a bill, a tip percentage, and a number of people, and shows what each person pays. It's small, but it has a real edge case (splitting $100 three ways has to add up to $100.00), and it has tests, so you can see the full loop.

Create an empty folder, initialize git so every step can be committed, and start Claude Code.

Then switch to plan mode. In plan mode Claude researches and writes a plan, but it can't edit your files until you approve. The quickest way in is /plan followed by the task. (Shift+Tab also cycles through modes; the status bar shows which one you're in.)

Notice what the prompt does: it says what the app does, what it must not use, how it will be checked (tests), and the edge cases you care about. Claude can't read your mind about any of those. The last line invites questions, so the plan is built on your answers instead of guesses.

Claude will probably ask you a few questions first, like whether the tip applies before or after splitting, or which currency to show. Answer them in plain language. Then it writes a plan: the files it will create, how the rounding works, and which tests it will write.

Read the plan. This is the cheapest moment to change direction, before any code exists. If something is off, reply with what you want instead and keep planning. When a plan is ready, Claude asks how to proceed:

• Yes, and use auto mode: Claude builds without stopping, while a background safety check blocks risky actions.
• Yes, manually approve edits: Claude builds, but asks before each file edit and command.
• No, keep planning: you give more feedback and it revises.

For your first project, pick Yes, manually approve edits. It's slower, and that's the point: you see every change. (Ctrl+G opens the plan in your text editor if you'd rather edit it directly.)

Now Claude creates the files one by one. Each edit shows up as a diff, with added lines and removed lines, and Claude waits. Read it. You don't have to understand every line, but you should be able to say what the change is for. Select Yes to accept, or decline and type what you want changed. Commands work the same way: when Claude wants to run node --test, it asks first.

If Claude heads somewhere you didn't ask for, press Esc. It stops right away, keeps the work so far, and waits for you to redirect it.

When Claude says it's done, don't take its word for it. Ask it to run the tests and show you the output. "All tests pass" in a summary tells you much less than the actual test runner output. You can also run them yourself with !node --test.

Then open the app. Ask Claude how, or open index.html from your file browser. Try the cases you care about: $100 split three ways, zero people, an empty bill. If something looks wrong in the browser, take a screenshot and paste it into the prompt (Ctrl+V, or Cmd+V in iTerm2 and Alt+V on Windows) with one sentence about what you expected.

Next, add a feature the same way, this time asking for the test first. A failing test written before the fix is the clearest definition of "done" you can give Claude, and it stops the classic beginner problem where Claude fixes one thing and quietly breaks another.

Two small habits that make a big difference here: say what "fixed" looks like, and ask for evidence (the test output) every time.

Before you commit, look at the whole change at once. /diff shows everything in your working tree, including Claude's edits. For a second opinion, /code-review reviews the current diff for bugs in a fresh subagent that never saw your conversation, so it isn't anchored on Claude's own reasoning.

Then commit. Claude Code makes git conversational: ask it to commit and it stages the files and writes a message based on what actually changed. Commit after each working step, not just at the end. Claude Code has its own undo (/rewind, below), but it only covers files Claude edited with its own file tools, not changes made by shell commands. Git covers everything.

That's the whole loop, and it scales from this toy app to real work: explore, plan, build with review, verify, commit. The table below maps each step to what you type.

Every new session starts with no memory of the last one, except for one file: CLAUDE.md. Claude Code loads it at the start of every session in that project. It's where you put what Claude can't figure out by reading the code.

Run /init in the project. Claude reads the codebase and writes a starter CLAUDE.md. From there, your job is mostly deleting lines. Anthropic's advice is to keep it short (under 200 lines) and include only:

• The exact commands to test, build, and lint, including how to run a single test.
• Places where the code is misleading, like an old pattern new code shouldn't copy.
• Decisions that aren't in the repo, like "no npm dependencies."
• Anything you've had to correct twice.

Leave out the folder layout: Claude reads the repo itself. Commit CLAUDE.md so it travels with the project. For the tip splitter, yours might look like the example below. The cheat sheet has a longer template and covers where personal and global CLAUDE.md files go.

One caveat: CLAUDE.md is guidance, not a lock. Claude follows it nearly every time, but not every time. Rules that must never be broken belong in hooks or permission deny rules.

Everything in a conversation is sent to the model again on every turn. That has two costs: a cluttered conversation gives worse answers, and it uses more of your plan's limits (or more money on the API). A few commands keep it under control:

• /clear between unrelated tasks. Finished the rounding feature and want to change the styling? Clear first. It costs nothing, your files and CLAUDE.md stay, and the next task doesn't keep paying for the previous one's history. /clear rounding-feature labels the old conversation so you can find it with /resume.
• /compact to shrink a long task you're still in the middle of. Add what to keep: /compact keep the test commands and the rounding rules. Claude Code also compacts on its own as the window fills, so you rarely run out.
• /rewind (or Esc twice on an empty prompt) to undo. Roll back the code, the conversation, or both to an earlier prompt. It makes trying a bold approach cheap.
• /context shows what's filling the window, and /usage shows your plan usage and what's eating it.

The most useful rule from Anthropic's best-practices page: if you've corrected Claude twice on the same thing and it's still wrong, don't try a third time. /clear, then write one better prompt that includes what you learned. A fresh start beats a conversation full of failed attempts.

Most first-week frustration comes from the same handful of habits:

1. Vague prompts. "Make it better" gets a guess. Name the file, describe the symptom, and say what done looks like.
2. Skipping the plan. For anything that touches more than one file, plan mode is where you catch the wrong approach before it's written.
3. No way to check the work. Without tests, a build, or a clear expected output, Claude can only tell you it thinks it's done. Give it a check, and ask for the output.
4. Approving diffs without reading them. Speed comes later. And keep --dangerously-skip-permissions for throwaway containers and VMs, never your laptop.
5. One endless session. Three unrelated tasks in one conversation means worse answers and faster limits. /clear is free.
6. Not committing. Commit each working step so a bad turn costs you minutes, not an afternoon.
7. Shouting in CLAUDE.md. ALL CAPS and "IMPORTANT" don't help current models. Short, plain lines do.
8. Using the biggest model for everything on the API. Sonnet handles most coding work and costs less than Opus. Switch with /model when a task needs more.

Once the loop feels natural, auto mode, subagents, skills, and MCP servers are the next layer. You don't need any of them to be productive.

• Keep a reference open: the Claude Code cheat sheet has every command, flag, and shortcut, plus templates for settings, subagents, skills, and hooks.
• Practice on more projects: pick something small you'd actually use, and run the same explore, plan, build, verify, commit loop. Our Claude Code project ideas list gives you a starting point.
• Learn it in a structured way: see the best Claude Code courses, most of which are free.
• Comparing tools? See Claude Code alternatives for how it stacks up against Cursor, Codex, and others.
• Build agents, not just use one: Claude Code is a model in a loop with tools, memory, and permissions. Our free AI Agents with PydanticAI course teaches you to build those pieces yourself in Python.