Why most Claude Code builds get stuck halfway
Here is what happens when you skip planning with Claude Code: you ask it to build something, it starts writing files, twenty minutes in you realize the approach it chose does not match what you actually needed, and now you are either starting over or spending an hour fixing a structural decision that was made in the first thirty seconds. This is the single most common reason a Claude Code build stalls.
The fix is not clever prompting or a better starting message. It is a planning pass before the first code request. When Claude knows the full picture upfront - what the project is, what it should do, how the user will interact with it, and what done looks like - it makes better structural decisions from the start. Those decisions are easy to change in a plan and expensive to change once they are woven into three files.
The plan-first prompt - how to ask Claude to think before it builds
The plan-first approach has one core rule: do not ask Claude to build anything until you have asked it to plan. The planning prompt gives Claude the context it needs to think at the architectural level rather than the implementation level. Here is the structure I use every time.
- Describe the project in two to three sentences: what it is, who uses it, and what problem it solves. Not the technical requirements - the purpose.
- Describe the key user actions: what does the user do in this thing, what happens when they click the main button, what do they see first.
- State what done looks like: the smallest working version you would actually use or show to someone.
- End with the planning instruction: 'Before writing any code, give me a build plan. List the main components you will create, the order you will build them in, and any decisions that will be hard to change later. Do not start building until I approve the plan.'
What a useful plan looks like - and what to push back on
A useful plan from Claude should name the main pieces of the project and the order they get built in. It should flag any decisions that lock in a direction - database choice, routing structure, auth approach - so you can review them before they become hard to change. And it should be specific enough that you can follow along and check whether it matches your mental model.
What to push back on: any time Claude proposes something more complex than you need. An auth system when you just need a password gate. A database when a JSON file would work for now. A component library when plain CSS does the job. The plan is the moment to swap these out. Once code is written, asking to simplify means rewriting files - and that costs time.
- Check the component list: does every piece have an obvious purpose, or are there things in there you do not recognize?
- Check the order: does building in the listed sequence make sense, or does it build a dependency before the thing that depends on it?
- Check the hard decisions: database, routing, auth, state management. These are the ones that ripple everywhere if they are wrong.
- Check the scope: is the plan describing the smallest working version you asked for, or has it expanded into more than you need right now?
Approving the plan and moving into build mode
Once you have reviewed the plan and pushed back on anything that looks off, approve it and tell Claude to proceed. From here, Claude should follow the sequence it laid out, and you should hold it to that sequence.
A simple approval message: 'Looks good. Build it in the order you described. After each main component is working, tell me what you just built and what comes next.' That last sentence gives you natural checkpoints through the build without interrupting the flow. Claude builds one piece, confirms, and moves to the next. You are reviewing progress at each checkpoint rather than at the very end when there are thirty files to untangle.
The CCC Build Brief - the two-minute version of this workflow
Inside Claude Code Club we call this the CCC Build Brief: a short structured description of the project that goes into Claude before the first code request. It does not have to be long. On most builds mine is eight to twelve lines. The format is always the same: what it is, who uses it, the three main things the user does, what done looks like, and the explicit instruction to plan before building.
The Build Brief lives in the project CLAUDE.md for any project that will run across sessions. That way every new session starts with context already loaded and the next conversation picks up in the right place rather than re-explaining the project from scratch. The planning pass is a one-time cost; the Build Brief pays off for the whole life of the project.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
Does Claude Code have an official plan mode?
Claude Code does not have a labeled 'plan mode' toggle in the settings. The plan-first workflow is a prompting approach: you explicitly ask Claude to produce a build plan and wait for your approval before writing any code. The key is ending your planning prompt with an instruction like 'do not start building until I approve the plan.' Without that explicit instruction, Claude will often outline the plan briefly and then start coding anyway.
How long should the planning pass take?
On most projects the planning pass takes two to five minutes. You write the Build Brief, Claude returns the plan in thirty to sixty seconds, and you spend a few minutes reading it and pushing back on anything that looks off. It is a small upfront cost that eliminates most of the mid-build structural problems that cost an hour to fix later.
What if Claude starts building before I approve the plan?
Tell it to stop, explain that you want to see and approve the full plan before any files are touched, and ask it to give you the plan without writing code. Claude will usually comply immediately. The key is being explicit upfront: 'do not write any code until I tell you the plan looks good.' Once Claude has a clear instruction to wait, it follows it.
Should I do a planning pass for every project?
For quick one-off scripts, a single isolated component, or a small bug fix, you do not need a planning pass. For anything that has multiple components, will run across sessions, or where a wrong structural decision would be expensive to fix, the planning pass is worth it. A useful threshold: if the project will take more than a couple of hours, plan first.
Last reviewed by David Iya on August 1, 2026
