On the six architectural pieces that turned my Claude Code workflow from a daily fight into a setup I now cannot run without, written for the version of you who runs Claude Code on a single project and is starting to feel the friction.

My Claude Code Setup for a Monorepo of Indie Projects

Six pieces that compounded into the workflow I cannot work without. The architecture, not the secrets.

The first six months of running Claude Code, I had a separate clone of the agent’s memory in every project folder. I lost work twice. I gave the same instruction to the same model three times in three different repos because each clone had forgotten the last conversation. I spent half my Saturdays re-explaining my own conventions.

The setup did not start clean. It got beat into shape.

Today I run Claude Code daily across a portfolio of independent indie projects, all inside a single monorepo, and the workflow is finally invisible. It runs underneath the work instead of fighting me for attention.

This is the architecture. Six pieces. Each one started as a hack and became load-bearing. None of them are secret. The secrets are in the cluster, the API keys, and the specific deploy configs, and those are not what makes this work.

1. One Monorepo, Many Independent Projects

Every project I run lives inside one root repository. Apatero Studio. Tool Index. Melodex. Books. Music. The personal site. All of it.

But the projects do not share dependencies. Each one has its own package.json or pyproject.toml, its own lockfile, its own node_modules, its own tooling. The monorepo is not a code-sharing experiment. It is a filing cabinet.

The submodule version of this setup did not survive. What did survive is the simpler shape: one repo, a projects/ folder, each project a fully independent world inside.

The payoff for Claude Code specifically is that one terminal session, one root directory, can see the full inventory. The agent gets a coherent picture of “what does this person work on” rather than a single project pretending to be the whole world.

The cost is discipline. No shared utilities. If two projects need the same helper, the helper gets copied. The cost is worth paying.

2. Every Deployment Config Lives in devops/, Nowhere Else

The second piece took me an embarrassing amount of time to learn. Deployment configs do not belong inside the project they deploy.

Inside projects/, every folder is application code. Server manifests, deployment scripts, ingress routes, cron definitions, none of that lives in the project folder. It all lives in a single top-level devops/ directory, organized per project.

When I need to ship something, the path is always devops/<project>/. When something breaks in production, I know exactly where the manifest is. When Claude Code needs to understand the deployment context for a feature change, it reads one folder, not seven scattered ones.

The rule is so strict that I wrote it into the root CLAUDE.md as a hard convention. No exceptions. When a deploy config drifts into a project folder by accident, fixing it is the first thing I do that week.

The single deploy folder is also the only place where the secrets layer is wired. The application code never touches a secret value. It reads from references that the deploy layer resolves. That separation is the difference between a project I can hand to a collaborator and one I cannot.

3. The research/ Folder Has Its Own Index, Auto-Generated

Every piece of research I do for any project lands in research/ at the root, with a numbered filename and a required header.

The header has a date, a status, and a topic. A small script regenerates the index from the headers any time I add a new doc. The index is committed, so a future Claude Code session can read it and know what already exists before starting any new investigation.

This single piece eliminated maybe forty percent of redundant agent work. The model used to start every “let me research X” task from scratch. Now it reads the index, sees there is already a doc on X, opens that doc, and continues from there.

Research docs also have to include an ELI5 section. This is not for the agent. It is for the version of me who reads the doc nine months from now and has forgotten everything except that the doc exists.

The folder is a small thing. It compounds into hours per month.

4. Claude Code’s Memory Is Symlinked Into the Repo

This is the piece nobody warned me about and the piece I wish someone had.

Claude Code has its own auto-memory system that lives in the user-level ~/.claude/ directory. The default behavior is that memories belong to a machine, not to a project. If I set up a new laptop, the memories are gone. If I open the repo from a slightly different shell context, the agent acts like a stranger.

The fix is a symlink. The agent’s per-project memory folder is symlinked into the repo at a known path. The repo owns the canonical copy. The user-level folder is the alias.

The result is that the memory travels with the codebase. Open the repo on a new machine, the agent remembers what it learned about the conventions, the tools, the user, the in-flight projects. Pull from git, the memories are current. The memory becomes part of the team artifact, not a private cache.

This single piece is the reason I can switch machines without losing the agent’s relationship with the work. It is also the reason I now treat the memory file as a real document, not a transient cache.

5. Every Daily Task I Repeat Becomes a Skill

The fifth piece is the one that scales. Anything I find myself doing more than twice becomes a custom skill.

Setting up a complex backend that needs a tunnel, a database container, three env files, and a specific seed script. That is a skill now. I do not need to remember the sequence. The agent does.

Running a multi-stage publish pipeline. Auditing a manuscript for canon consistency across two books. Compiling a print PDF from chapter markdown. Generating a hero image from a slug. All skills.

Each skill is a small file with a name, a description, and the steps to run. The agent reads the file, executes the steps, asks me only for the inputs that vary. The first run of the skill takes the same time as doing the task manually. The hundredth run takes thirty seconds.

The skill folder is now larger than most of my project folders. It is the highest-leverage code I have written this year, and almost none of it is application code.

6. One Bootstrap Script Sets Up Anything

The last piece is small but matters out of proportion.

The repo has a single setup script at the root that knows how to bootstrap any project inside it. Run it with a project name and it handles the env files, the installs, the post-setup instructions. Run it with --all on a fresh machine and the whole monorepo is workable in fifteen minutes.

The first time I needed this was the morning I tried to start a new project on a borrowed laptop and realized I had no documented path from zero to running. The script took two hours to write. It has saved me at least forty.

The other reason the script matters is that it is the on-ramp for anyone I ever hand the repo to. Without it, onboarding a collaborator costs me a half-day. With it, the collaborator runs one command and reads one printed message.

What the Setup Buys Me

It buys me one thing. The work is visible enough that I can let the agent do most of the boring parts.

Before this architecture, every Claude Code session started with five minutes of orientation. Where are we. What is this project. What are the conventions. What did I tell you last time. After this architecture, the session starts with the work.

The same agent that helped ship indie products to revenue cannot do that on a chaotic repo. It can do it on a repo where the structure already answers the boring questions.

The setup also buys me a useful kind of discipline. The conventions in the root CLAUDE.md are enforced because if I break them, the agent gets confused. The agent’s confusion is feedback. The feedback keeps the conventions alive.

What the setup does not buy me is taste, judgment, or product instinct. None of those live in the architecture. They live in me, and the architecture only makes them more accessible by removing the friction that was eating them.

What I Would Tell the Version of Me Who Was About to Start

The version of me one year ago would have skipped most of this because it felt premature.

He was wrong. The setup pays back fast. By month two of consistent use, the structure has saved more time than it took to build. By month six, the structure is the reason the work compounds at all.

The instinct to look for the perfect agent setup before starting is a trap. The setup does not arrive. It evolves. Mine arrived piece by piece, each one in response to a failure, none of them designed in advance.

Start with the monorepo and the devops folder. Add the research index when you notice you keep redoing the same research. Add the memory symlink when you notice the agent has amnesia between machines. Add skills when you notice yourself typing the same sequence twice. Add the bootstrap script the morning you cannot remember how to set up your own work.

The setup is not the secret. The setup is what makes the work visible enough that the actual secrets even matter.

If you run Claude Code on a single project today, you do not need this whole architecture yet. You need the first piece. Move your projects into a monorepo this Saturday. The other five will follow in their own time, each one earned by a specific failure that will tell you exactly what to add next.