Phase by phase: how I build complete products with Claude Code

My first attempts at building a product with an AI agent all failed the same way. I'd describe the whole thing in one long prompt, the agent would start strong, and a few hours later I'd have half of five features, a context window full of stale decisions, and a token bill for the agent re-reading and re-explaining the same code over and over.

The model wasn't the problem. The work had no shape. Nothing told the agent what was done, what was next, or what "done" even meant.

After a lot of trial and error I settled on a process that is almost boring in how straightforward it is. It keeps token usage down, produces output I actually planned, and lets me build complete products, UI and backend, with Claude Code. This is how it works.

The core idea: a tracker the agent owns

Everything revolves around one markdown file: a progress tracker. It lives in the repo, it's split into phases, every phase is split into small tasks, and the agent is responsible for keeping it accurate.

That file becomes the project's memory. A context window forgets; a file in the repo doesn't. Any session, fresh or resumed, starts by reading the tracker and knows exactly where things stand without me explaining anything again.

1. Define the product first

Before any code, I write down what I'm building:

• What the product is, and who it's for.
• The features, in plain language, each with a line on why it exists.
• Constraints: the stack, where it deploys, anything that's already decided.

This is the only part I insist on doing carefully myself. Every vague sentence here turns into a wrong assumption later.

2. Ask for the tracker, not the code

Next, I ask Claude to turn that brief into a tracker: phases in a sensible build order, each split into tasks small enough to finish and verify in one go. I review it and adjust before a single file of code exists.

Legend: [x] done · [~] in progress · [ ] todo · 🙋 needs input from me
 
## Phase 1 — Foundation
- [x] Scaffold the app, design tokens, layout shell
- [x] Auth: sign-up, login, session handling
 
## Phase 2 — Core feature
- [~] Data model + API endpoints
- [ ] List and detail screens
- [ ] Validation and empty/error states
 
## Phase 3 — Polish
- [ ] Responsive QA, accessibility pass
- [ ] SEO and metadata
 
## Log
- 2026-10-19 — Phase 1 complete. Lint + build clean.

Reviewing a plan is far cheaper than reviewing code. If the order is wrong or a feature is missing, I fix one line of markdown instead of unwinding a day of work.

3. Build one phase at a time

Then the instruction is simple: build Phase 1. Only Phase 1.

Because each phase is scoped, the agent only needs the context for that phase: the tracker, the brief and the files it touches. It doesn't wander into Phase 4 because an idea looked interesting, and it doesn't re-architect what Phase 1 already settled.

4. Validate, then update the tracker

A phase isn't done when the code is written. It's done when it has been checked: lint and build pass, tests run, and for UI work the agent takes screenshots and looks at them. Only then does it tick the tasks off and add a line to the log.

That closing step is what makes the whole thing resumable. If a session ends mid-phase, the [~] marker and the log say exactly where to pick up.

5. New ideas become sub-phases, not detours

Ideas show up mid-build; that's normal. The trap is letting them hijack the current phase.

So when something new comes up that isn't in the tracker, I don't say "build this now." I say "add it to the tracker as a sub-phase." It becomes Phase 2.1 with its own tasks, the current phase finishes cleanly, and the new work gets built later in the same disciplined way. The plan grows without ever falling apart.

Why this saves tokens

Most wasted tokens in agentic coding come from three things, and the tracker removes all of them:

• Re-deriving context. Without a tracker, every session rebuilds its picture of the project by reading half the codebase. With one, a single file read does it.
• Rework. Scoped phases plus validation mean mistakes are caught while they're small, not after three more features are built on top of them.
• Drift. An agent with a clear, finite task stops when it's done instead of "improving" things nobody asked for.

Let Claude run the agents

I don't orchestrate agents by hand. Claude Code already splits work up internally: it sends a subagent to explore the codebase or runs independent tasks in parallel, and only the conclusions come back into the main thread. My job is the plan and the checkpoints; delegation is its job.

Tools and skills that plug into the loop

Through MCP, the same session can reach the tools a real product needs:

• Figma for design. The agent reads frames and builds UI against them instead of guessing.
• Vercel and Cloudflare for deployment, so shipping a phase can be part of the phase.
• Other skills as the project needs them: a skill packages instructions for a specific kind of task, and the agent loads it only when relevant.

One skill I always install is andrej-karpathy-skills, a set of guidelines built on Andrej Karpathy's observations about how LLMs go wrong when they code. Its four principles line up neatly with this workflow:

1. Think before coding. State assumptions and ask when something is ambiguous, rather than silently picking an interpretation.
2. Simplicity first. Write the minimum code that solves the problem, with no speculative abstractions.
3. Surgical changes. Touch only what the task needs, which keeps each phase contained.
4. Goal-driven execution. Turn tasks into verifiable goals, which is exactly what phase validation is.

The prompts, in practice

The whole process runs on a handful of prompts:

• "Here's the product and its features. Create PROGRESS.md with phases in build order, each split into small tasks. Don't write code yet."
• "Build Phase 2. Validate it with lint, build and tests, then update the tracker and the log."
• "I want X. It isn't in the tracker, so add it as a sub-phase under Phase 3. We'll build it after the current phase."
• "Read the tracker and continue from where we left off."

What it adds up to

With this loop I can build a complete product, frontend and backend, that's structured to scale rather than patched together. More importantly, it's predictable: at any moment the tracker tells me, and the agent, exactly what's done, what's next and what's waiting on me.

This site is an example. It was built from a PLAN.md and a PROGRESS.md with eight phases, from foundation to deploy, each validated before the next began, with every change logged along the way.

The models will keep getting better. But the lesson from all the trial and error is that agents don't need more freedom; they need structure. Give the work a shape, and they'll fill it in.