Your First Claude Code Project

Five minutes. That is all you need to ship your first working app with Claude Code. Skip Hello World. We are going to build a personal task manager that you will actually run every day.

Quick Win: Paste this to start:

mkdir smart-todos && cd smart-todos && claude

Your workspace exists. Claude Code is live inside it. Watch what happens next.

Tell Claude what you want, plainly:

The prompt: "Create a CLI task manager where I can add tasks, mark them done, and see my list. Make it save to a file so tasks persist."

A full plan comes back. You will see Claude reason through:

• File structure (a single Node.js app)
• Core behavior (add, complete, list)
• Persistence (a JSON file on disk)
• Interface (clean terminal output)

What Claude Is Doing Under the Hood

That prompt is not a text generator firing a paragraph at you. A tool chain runs. Claude reads your current directory first, sees that nothing is there, and builds a plan: what to write, in what order, which dependencies to pull. Then it picks up the Write tool for each file, the Bash tool to run npm init -y and install packages, and sometimes the Read tool to double-check what it just wrote. Every tool call surfaces in the conversation as it happens.

A chatbot dumps code into a response box. Claude Code actually edits your filesystem and runs commands in your terminal. The files on disk are real. The node_modules folder that shows up is real too.

Claude creates working files directly:

// Claude creates tasks.js automatically
#!/usr/bin/env node
import fs from 'fs';
import path from 'path';

const TASKS_FILE = path.join(process.cwd(), 'tasks.json');
// ... complete working code appears

Test your new task manager immediately:

node tasks.js add "Learn Claude Code"
node tasks.js add "Build something amazing"
node tasks.js list

Expected output:

✓ Added: Learn Claude Code
✓ Added: Build something amazing

Your Tasks:
□ 1. Learn Claude Code
□ 2. Build something amazing

Two minutes. File persistence, error handling, and tidy output formatting are all working, in a real CLI app.

Now the fun part. You refine through conversation. Try these:

Add colors: "Make completed tasks show in green and pending in yellow"

Priority system: "Let me add priority levels - high, medium, low"

Due dates: "Allow setting due dates and show overdue tasks in red"

Search function: "Add ability to search tasks by keyword"

Each request lands almost instantly. No Stack Overflow tabs. No config rabbit holes. Describe the behavior, watch it show up.

The old way forced you to know everything before you started:

• Which libraries to pick
• How files should be laid out
• Command-line argument parsing
• File I/O operations
• Error handling patterns

Claude Code drops all of that friction. You describe the outcome. Claude handles the plumbing.

What you actually built:

• Cross-platform file operations
• JSON data persistence
• Argument parsing
• Colorized terminal output
• Proper error handling
• User-friendly help messages

A project like that usually chews up real setup time and dependency hunting. Here, one prompt covered it.

Stuck already? The installation guide has the detailed setup walkthrough.

"Permission denied" when you run tasks.js on Mac or Linux:

chmod +x tasks.js

"Module not found" errors:

npm init -y && npm install commander chalk

Want to run it from anywhere? Add this to package.json:

{
  "bin": {
    "todo": "./tasks.js"
  }
}

Then run npm link. Now todo add "anything" works from any folder on your system.

Sometimes the first attempt misses what you had in mind. That is normal. Conversational development expects it.

Claude wrote code but it errors out when you run it. Paste the error straight into Claude Code. Say: "I got this error when running the app" and drop in the full stack trace. The error gets read, the cause gets identified, the file gets fixed. Most first-run issues are missing dependencies or a Node.js version mismatch.

The app runs but does not do what you described. Be more specific in the next prompt. Skip "it's not right" and say exactly what you expected and what you saw. "The list command shows tasks in the order they were added, but I want them sorted by priority" gives Claude a concrete target. Vague feedback produces vague fixes.

Claude built too many files or over-engineered it. Broad prompts cause this. To Claude, "task manager" can imply a database, a config system, and several modules. On the next pass, pin the scope: "a single-file Node.js script, no database, store tasks in a JSON file." Tight scope produces tight code.

Claude keeps asking for permission before running commands. That is the permission system protecting your machine. It pauses on shell commands, package installs, and writes outside your project. Type "y" to approve each one, or configure auto-approval for the commands you already trust.

What just happened:

• You described an idea in plain English
• Claude built a complete, working app
• You are running it in under five minutes

This is conversational programming. Think in problems and solutions. Skip syntax and APIs.

Your task manager works. Try this next:

Next prompt: "Add a web interface so I can manage tasks from my browser. Keep the CLI working too."

An Express server shows up. So does the HTML interface. Your CLI still runs, untouched. A full-stack app in minutes.

Or branch in a different direction:

• Browse real project examples for ideas
• Configure Claude Code to match your workflow
• Troubleshoot common issues when something goes sideways

Traditional tutorials teach syntax. What you just picked up is the Claude Code development pattern. The same five-step loop works on a CLI tool and on a full-stack SaaS alike.

1. Describe the outcome you want. Focus on what the finished product does, not how you would build it. "A task manager where I can add, complete, and list tasks" beats "create a Node.js script using Commander.js with a JSON file store." Implementation details are Claude's problem. Steering comes later.

2. Let Claude architect the solution. Your description gets broken into file structure, dependencies, and build order. Libraries get picked. Patterns get chosen. Hundreds of tiny decisions that would cost you an hour of research get made for you. Disagree with any of them? Just say "use sqlite instead of JSON files" and move on.

3. Test immediately. The moment Claude stops writing, run the output. Do not line-read first. Real issues (missing dependencies, runtime errors) show up fast when you run the thing. Any error pasted back into Claude becomes an instant fix.

4. Enhance conversationally. Every follow-up prompt adds a feature or tweaks behavior. "Add due dates." "Make the output prettier." "Add a search command." Existing code gets modified in place, and what already works stays working. This loop is faster than planning up front because every decision is made against a running prototype.

5. Deploy with confidence. By the time you are three or four enhancement cycles in, your app has been tested at every step. Edge cases got surfaced during conversational development. Push to Git. Ship it.

The pattern holds at any size. Solo devs build whole SaaS apps with it. Teams use it to prototype features before sprint planning.

You built something real. The next step is making Claude Code behave the way you think. Two guides are where to go:

Configure Claude Code covers settings, permissions, and model selection. That is where you turn on auto-approval for trusted commands, pick between Sonnet and Opus by task, and tune the terminal experience.

The CLAUDE.md guide walks you through the file that controls how Claude behaves on every project. Of everything you can do after your first project, this one pays back the most. A solid CLAUDE.md means your coding standards get followed, your preferred patterns get used, and decisions get made the way you would make them.

Beyond configuration:

• Read the skills guide to give Claude deep expertise in a domain
• Explore agent fundamentals to run several parallel agents on big tasks
• Jump into troubleshooting when things break