Build a Complete Product from Scratch

The Big Idea

Chapters 1–8 covered the individual parts. This chapter shows that Claude Code's true power is not any single feature — it is the chain reaction when the features work together.

The book is honest about scope. On the day CCTV filmed the author, he built a working mini-product in 10 minutes on camera. A commenter asked: "Can something built in 10 minutes even count as a product?" His answer: no — 10 minutes gives you a working prototype. The gap between prototype and product is filled with user feedback, edge cases, performance tuning, and app-store review. Kitty Light took an hour for v1 but months of iteration (Pro version, mini-program, HarmonyOS).

Why This Topic Matters

• Individual techniques are only useful when you can sequence them into a finished product.
• It shows where the time actually goes (Phase 2, core features) and where beginners fall down.
• It reinforces that your job through the whole build is making product decisions, not writing implementation code.

The Example Project: "AI Weekly Report Assistant"

What it does: connect to your GitHub, pull all of this week's commits, use AI to summarise them into a readable report page, and share it with your team in one click. Every engineer does this manually every Friday — about 30 minutes. The goal is to cut it to 10 seconds.

Why this example (it checks three boxes):

Phase 0 — Don't Rush to Write Code

The classic beginner mistake: the moment an idea hits, tell Claude to start coding — then realise halfway that the requirements were not thought through, and tear it all down. The habit instead: let Claude interview you first.

claude "I want to build a weekly report tool. Before writing any code,
interview me to understand the requirements. Ask me questions one at a
time about target users, core features, and technical constraints."

Claude asks like a product manager: Who are the target users (individual developers or a team)? What are the core features (just generate the report, or share it too)? Technical preferences (where deployed, what framework)? Any design references?

Then consolidate the answers into a spec:

claude "Based on our discussion, create a SPEC.md file that captures
all requirements, user stories, and technical decisions."

Why start a new session for development: requirements gathering is conversation-heavy and burns context. Once SPEC.md is locked in, open a fresh session; it automatically loads SPEC.md and CLAUDE.md, giving a clean context for coding. (This is the "when to start a new session" principle from Chapter 6, applied.)

Phase 1 — Project Initialization

claude "Create a Next.js project called weekly-report with Tailwind CSS.
Set up the basic folder structure following SPEC.md requirements.
Include TypeScript, and configure ESLint."

Claude runs npx create-next-app, installs dependencies, configures Tailwind, and creates the base structure. The result looks roughly like:

weekly-report/
├── app/
│   ├── layout.tsx
│   ├── page.tsx
│   ├── api/
│   │   ├── github/route.ts
│   │   ├── summarize/route.ts
│   │   └── auth/[...nextauth]/route.ts
│   └── report/[id]/page.tsx
├── components/
├── lib/
├── CLAUDE.md
├── SPEC.md
├── tailwind.config.ts
└── package.json

Configuring CLAUDE.md (Chapter 5, in practice)

# CLAUDE.md
## Project Overview
AI-powered weekly report generator. Connects to GitHub, summarizes
commits with AI, generates shareable report pages.

## Tech Stack
- Next.js 15 (App Router) + TypeScript
- Tailwind CSS for styling
- NextAuth.js for GitHub OAuth
- Claude API (via Anthropic SDK) for summarization

## Code Style
- Use server components by default, 'use client' only when needed
- API routes in app/api/, use Route Handlers
- Prefer named exports
- Error handling: always use try-catch in API routes

## Testing
- Run `npm run lint` before committing
- Test API routes with curl before building UI

What this buys you: every future session already knows the project's technical decisions and conventions — no re-explaining.

Phase 2 — The Build (the biggest time sink)

Start with an architecture discussion in Plan mode (/plan) before touching a file:

"I need to implement the core flow: GitHub OAuth login -> fetch this
week's commits -> send to Claude API for summarization -> display
the report. Let's discuss the architecture before coding."

Claude lays out a full technical proposal (API route design, data flow, component breakdown). You raise questions and adjust — like whiteboarding with a senior engineer. Then exit Plan mode:

"Plan looks good. Now implement it step by step. Start with GitHub
OAuth, then the commit fetching API, then the AI summarization."

Claude progressively creates app/api/auth/[...nextauth]/route.ts (NextAuth), lib/github.ts (GitHub API wrapper), and app/api/summarize/route.ts (Claude API).

Verify after every module

Phase 3 — Make It Look Good

Get the features running first, then care about aesthetics. Claude Code accepts image input — screenshot the page and paste it in:

claude "Here's a screenshot of the current report page.
[paste screenshot]
Issues: 1) The header is too cramped 2) The commit list needs
better spacing 3) Add a share button in the top right"

Claude reads the screenshot, understands the visual problems, and makes precise CSS/component changes. This screenshot → feedback → fix loop replaces flipping between mockups and code. Then handle responsive behaviour:

"Test the report page on mobile viewport (375px width). Fix any
layout issues. The share button should be full-width on mobile."

Phase 4 — Extending the Stack (Chapter 7, in practice)

Create a Skill

Collapse the whole "generate a report" routine into one command. Create .claude/skills/generate-report/SKILL.md:

# /weekly-report
Generate this week's report.
## Steps
1. Run the dev server if not running
2. Call /api/github to fetch commits since last Monday
3. Call /api/summarize to generate the report
4. Open the report page in browser
5. Show the shareable URL

Now /weekly-report runs all of that automatically — one command, report in 10 seconds.

Add MCP: connect Slack

claude "Add a Slack MCP server so the generated report can be
automatically posted to #team-updates channel. Use the Slack
Web API with a bot token."

Claude configures the MCP server and registers the Slack connection. The /weekly-report skill can then include a final step: posting to Slack.

Set up a Hook: auto-lint

claude "Set up a pre-commit hook that runs ESLint and TypeScript
type checking. If there are errors, fix them before committing."

Now every git commit verifies code quality first — the classic Hook use case: automatic checks at key checkpoints.

Phase 5 — Deploy to Production

claude "Deploy this project to Vercel. Set up the environment
variables for GitHub OAuth, Claude API key, and Slack bot token.
Also create a GitHub Actions workflow that runs lint and type
check on every PR."

Claude runs the deployment commands, configures environment variables, and creates the CI/CD config — no Vercel dashboard, no hand-written YAML. You get a live URL; run the full flow (login → fetch commits → generate report → share) to confirm. Optionally:

claude "Add a Claude Code Action to the GitHub repo that
automatically reviews PRs for code quality and potential bugs."

Looking Back: What Each Phase Used

Expected time: 5–8 hours if it goes smoothly (Phase 2 is the biggest sink — OAuth setup and API debugging need repeated verification; fiddly details like environment variables and callback URLs eat 10–15 minutes each). A full day is normal if things do not go smoothly.

By hand: a full-stack engineer who knows Next.js and OAuth well: 2–3 days. Someone less familiar: a week. The real difference is not just speed — throughout, you are making product decisions ("what should the report include?", "does the share page need a login?") instead of hunting Stack Overflow for "how do I configure the NextAuth GitHub provider?"

Hard-Won Lessons (the five that matter most)

1. Break requirements down — one step at a time

Break things into the smallest verifiable steps. Only move to the next step after the current one passes verification.

2. Get the minimal version running first, then layer on

This is product strategy (versus lesson 1, which is about instructions). Kitty Light's first version had exactly one feature: open app, screen goes white, brightness maxed. The author took a selfie, decided it worked, and only then added colour temperature, a brightness slider, timed shooting. Build the simplest working version, use it yourself for a couple of days, discover what you actually need before adding.

3. Verification is more important than development

Claude writes fast enough to create an illusion of correctness. A person writes ~200 lines/day (verifiable); Claude can write 2,000 lines/hour. If you do not verify as you go, problems compound and surface later at much higher cost. Rule: the moment a feature module is done, open the browser or run the tests. Fix problems immediately.

4. Don't tackle too many unrelated things in one session

Every session has a context window limit. Frontend tweaks + backend debugging + deployment + bug fixes in one session turns context into noise and degrades responses. The author's split:

Session 1: Project scaffolding + foundation architecture
Session 2: Core backend logic
Session 3: Frontend pages and interactions
Session 4: Testing and bug fixes
Session 5: Deployment and CI/CD

Context passes between sessions through CLAUDE.md and the codebase itself.

5. Product sense is your biggest lever

Claude can write code, polish UI, configure deployment, fix bugs. It cannot decide: what problem should this product solve? Who are the users? Which features matter and which to cut? "AI can multiply your execution speed by 10× — but if you're pointed in the wrong direction, you just arrive at the wrong destination 10 times faster." Kitty Light's code is unremarkable; it succeeded because it precisely solved a real problem.

Visual Mental Model: The Chain Reaction

Interview you  ─►  SPEC.md
                     │  (new session loads it)
Scaffold      ─►  project + CLAUDE.md
                     │
Plan mode     ─►  architecture agreed
                     │
Build module  ─►  VERIFY  ─►  build next module  ─►  VERIFY ...
                     │
Screenshot    ─►  UI fixes (batched)
                     │
Skill + MCP + Hook  ─►  /weekly-report in 10 seconds
                     │
Deploy + CI/CD ─►  live URL, PR auto-review

Traps to Avoid (from the chapter)

Common Beginner Mistakes

• Coding before the requirements are clear — skipping the Phase 0 interview and SPEC.md.
• Dumping the entire product vision into one prompt.
• Building every imagined feature instead of a one-feature MVP you actually use.
• Trusting fast code is correct code — not verifying each module.
• One endless session covering scaffolding, backend, frontend, tests, and deploy.
• Adopting Claude's architecture choice without thinking it through.
• Letting environment variables live only in your head, then breaking in production.

Best Practices

• Phase 0 always: let Claude interview you; lock a SPEC.md; start development in a fresh session.
• Configure CLAUDE.md early so every session knows the stack and conventions.
• Discuss architecture in Plan mode before writing files.
• Verify after every module — browser or curl or tests.
• Get features working, then polish UI with batched screenshot feedback.
• Wrap repetitive workflows into a Skill; connect external steps with MCP; enforce checks with a Hook.
• Split work across focused sessions; pass context via CLAUDE.md and the codebase.
• Keep directional decisions (what, which tech, who for) for yourself.
• Ship a minimal version, use it, then iterate on real feedback.

Interview / Revision Questions

1. What is the difference between a prototype and a product, per this chapter?
2. What three boxes does a good teaching project need to check?
3. Why do you let Claude interview you in Phase 0, and why start development in a new session afterwards?
4. What role does SPEC.md play for the rest of the project?
5. Why configure CLAUDE.md right after scaffolding?
6. What happens in Plan mode before Phase 2 coding?
7. Why is "verify after every module" called the single most important habit?
8. Describe the screenshot → feedback → fix loop and why batching issues helps.
9. In Phase 4, what does the Skill do, what does the MCP add, and what does the Hook enforce?
10. Roughly how long does the whole project take, and which phase dominates?
11. List the five hard-won lessons.
12. Name three traps and their fixes.

Practice Exercises

Quick Memory Map

Build a Complete Product from Scratch
│
├── Prototype (10 min) != Product (months of iteration)
│
├── Six phases
│   ├── 0 Interview -> SPEC.md   (then NEW session)
│   ├── 1 Scaffold + CLAUDE.md
│   ├── 2 Plan mode -> build module -> VERIFY -> repeat
│   ├── 3 Screenshot -> batched UI fixes
│   ├── 4 Skill + MCP + Hook
│   └── 5 Deploy to Vercel + CI/CD
│
├── 5 hard-won lessons
│   ├── 1 Break requirements into smallest verifiable steps
│   ├── 2 Minimal version first, then layer on
│   ├── 3 Verification > development
│   ├── 4 One category of work per session
│   └── 5 Product sense is your biggest lever
│
└── Traps: scope creep / context pollution / skipping verify
           / env-var chaos / over-delegating decisions

Complete Chapter Revision

1. Claude Code's power is the chain reaction of features together, seen by building one real product end to end.
2. 10 minutes buys a prototype; a product needs feedback, edge cases, tuning, and review.
3. The example is an AI Weekly Report Assistant (GitHub commits → AI summary → shareable page → Slack).
4. Phase 0: let Claude interview you, produce SPEC.md, then develop in a fresh session.
5. Phase 1: scaffold with one prompt, then write a lean CLAUDE.md.
6. Phase 2: Plan mode for architecture, then build module by module, verifying each.
7. Phase 3: get features working first, then polish UI with batched screenshot feedback.
8. Phase 4: a Skill collapses the workflow, an MCP posts to Slack, a Hook enforces lint.
9. Phase 5: Claude handles Vercel deploy and CI/CD; you get a live URL and optional PR auto-review.
10. Whole build: 5–8 hours (Phase 2 dominates); by hand it is days to a week.
11. Five lessons: break requirements down, minimal version first, verify over develop, one category per session, product sense is the biggest lever.
12. Avoid the five traps; AI proposes, you decide directional and architecture choices.

Final Takeaway

This teaching edition is based on the supplied April 2026, 2nd edition of Claude Code: The Complete Guide (§09, "Build a Complete Product from Scratch"). Framework versions, file paths, commands and time estimates reflect that edition and may change over time.