The right first project is specific, personal, and small enough to finish in one session.
The Single Most Common Mistake
CEOs starting with Claude Code almost universally pick a project that's too large.
"I want to build an internal CRM." Too large. "I want to automate our entire reporting pipeline." Too large. "I want a dashboard for all our KPIs." Too large.
These are real goals. They're also multi-week projects that require understanding your data structures, your team's workflows, and dozens of design decisions you won't know how to make until you've built something smaller.
Your first project should be completable in 2 hours.
Not a proof of concept. A working tool. Small scope, real value, done.
How to Choose
Answer these questions:
- What do I do manually every week that takes more time than it should?
- What piece of information do I wish I had but don't, because nobody's built the thing that shows it?
- What report/summary/export do I ask someone else to prepare for me that I could have on demand?
The answer to one of these is your first project.
Examples that work well:
| Problem | First Project |
|---|---|
| Monday morning report takes 2 hours | Script that pulls numbers and emails you a formatted summary |
| Can't see key metrics without logging into 3 systems | Local dashboard that aggregates the numbers in one place |
| Team meeting notes scattered across emails and docs | Script that converts a raw notes file into structured action items |
| Invoice tracking is a mess | Simple script that reads a folder of PDFs and outputs a CSV summary |
| I want to know when a competitor changes their pricing | Script that checks their pricing page daily and alerts you to changes |
Pick one. One specific problem. One session.
Defining It Well
The quality of what Claude Code builds is determined almost entirely by the quality of how you describe what you need.
Vague description produces vague results. Here's the difference:
Vague:
"I need a report of our sales."
Precise:
"I have a Google Sheet at this URL with columns: Date, Salesperson, Deal Name, Amount, Status. I want a Python script that downloads it, filters for Status='Closed Won', groups by Salesperson, sums the Amount column, and prints a clean table showing each salesperson and their total for the current month."
The second description gives Claude Code everything it needs. No ambiguity. No interpretation required.
The Briefing Template:
Before you open Claude Code, write this out in plain language:
THE PROBLEM: [What's frustrating you right now? What are you doing manually?]
THE INPUT: [What data does this tool need? Where does it come from?]
THE OUTPUT: [What should the finished result look like? A file? An email? A screen?]
THE TRIGGER: [When should this run? Manually? Daily? When something happens?]
THE CONSTRAINTS: [Anything it must NOT do. Any systems it can't touch. Any format it must use.]
Fill this in before you start. Hand it to Claude Code at the beginning of the session.
Running the Session
Start with the brief:
I want to build: [paste your brief]
Let's start with the simplest version that works. What do you need from me to begin?
Stay present:
Don't walk away. Watch what it builds. When it asks a question, answer it specifically. When it makes a decision you don't understand, ask:
Why did you choose that approach?
Test immediately:
When it says it's done, run the thing. Don't trust "it should work." Verify that it does what you described.
Iterate:
The first version will be 80% right. That's normal. Tell it specifically what's wrong:
The output is correct but it's hard to read. Can you format the numbers with commas and right-align the amount column?
Not "make it better." Specific.
When Things Break
They will. This is not failure. This is building.
When Claude Code hits an error, it will read the error message and attempt to fix it. Let it try. If it tries twice and fails, read the error yourself and ask:
I'm seeing this error: [paste the error]. What's causing it and what's the fix?
If you're completely stuck after three attempts:
- Ask it to try a completely different approach
- Simplify the scope: "Let's get a version that works for 10 rows first, then scale it"
- Start fresh in a new session with a cleaner brief
Debugging is part of building. Every developer spends a significant portion of their time on it. Claude Code compresses it significantly. But it doesn't eliminate it.
When You're Done
Your session is complete when:
- The tool runs without errors
- The output matches what you described
- You understand what it built well enough to explain it in one sentence
That third point is the standard. If you can't explain what it built, you don't own it yet. Ask Claude Code to explain it. Ask follow-up questions until you do.
Document it:
Before closing, ask:
Add a comment at the top of the main file explaining what this does, what inputs it needs, and how to run it.
Future-you will thank present-you.
What You've Proved
You've proved that you can take a specific problem, define it precisely, direct a build, and ship a working tool.
That is the whole skill. Everything else in this guide is variation on that process.
Next: Talking to Claude Code