How I ship ten projects at once using Claude Code as a build engine
{{DRAFT — Michael review required}} This post was ghostwritten by Claude Code in Michael's voice. Nothing here ships publicly without his review.
The version of this question I get asked most is "how do you have ten projects going at the same time and not lose the plot?" The honest answer is: most days I almost do. The system is what keeps me from it.
The studio isn't me, exactly
I'm the operator. Pamela handles research, fact-checking, and the human side of client work. Claude Code is the build engine. The three of us cover roles that would take a six-person agency to cover badly.
Where Claude Code fits
Claude Code doesn't write specs for me. I write the spec. Claude Code executes the spec. The skill is in writing specs at the right level of detail — not so vague that the agent guesses wrong, not so micromanaged that I could have just typed the code myself.
A typical morning:
- I read the overnight work — tests, deploys, the activity log.
- I decide what shipped, what needs a decision, and what's blocked.
- I write a handful of specs, most of them under 300 words.
- I hand them to Claude Code with the project context loaded.
- I review the PRs as they come back, ship or redirect.
The mistake people make is treating the agent as a teammate who needs consensus. It isn't. It's a senior engineer who needs a precise brief and a clear success criterion.
Memory, not just prompts
Every project has a CLAUDE.md at its root describing the stack, the deploy target, the approval rules, the things that already went wrong. The global CLAUDE.md at my home directory covers the rest: my preferences, the infrastructure map, the security levels per project. The agent reads these without being asked. That's most of the difference between "Claude Code" and "ChatGPT with a web interface."
Sub-agents
The Explore, Plan, and general-purpose sub-agents are the secret weapon for big codebases. Throw a sub-agent at a search that would cost me 40 keystrokes of grep, get an answer back, keep my main context clean. Context windows are a budget. Burning them on file navigation is how you run out before lunch.
The commit cadence
Every milestone commits and tags. stable-v0.1 after the first working feature. stable-v0.2 after the next. When something breaks at stable-v0.5, I diff against stable-v0.4. That's usually enough to isolate the change. It's the oldest engineering discipline there is, and the reason I can move fast with a project I haven't touched in three weeks.
What Claude Code is bad at
- Picking which feature to build. That's my job.
- Saying no to scope creep. Also my job.
- Calling a client to explain a missed deadline. That one's Pamela's when I've messed up.
What I haven't figured out yet
Estimating how long a project will actually take when the build engine is this fast. Most of my old heuristics are wrong by half. I'm recalibrating as I go.
If you want to see the full stack + workflow, the MSM stack post is the next one to read.