How I Run 6 Client Projects Solo With Claude

Six active client engagements. Settlement Scout automating legal claim submissions. Ballparker generating cost estimates across three synced repos. Social Butterfly managing a content calendar for a client on a hard May launch deadline. Two SaaS products in parallel. A local OSINT tool for collections work. All of it running through one developer, no team, no project manager.

People ask how that works without everything collapsing into chaos. The honest answer is that it mostly does not feel chaotic, because the system handling coordination is not in my head. It is encoded in Claude, in a way that is reproducible, auditable, and gets better over time instead of worse.

This post explains how that system actually works. Not the marketing version. The wiring underneath.

The problem Claude solves that is not obvious

Most people use Claude like a smarter search engine or a faster Stack Overflow. You ask it something, it answers, you close the tab. That is useful, but it misses the structural problem that kills solo developers at scale: context switching costs.

Every time you switch between projects, you pay a tax. You have to reload: what was I doing, what decisions did I make, what is the next action, what are the constraints I was operating under? If you are moving between six projects in a day, you pay that tax six times. And if anything has changed since you last touched a project, the tax is higher.

Claude does not eliminate context switching. What it does is give you a place to externalize the context so the reload cost drops to near zero. You tell Claude what you know, what you decided, what the next action is. Claude holds it. When you come back, you ask Claude to catch you up and you are back at full speed in about thirty seconds.

But that only works if Claude actually holds the context reliably. Which requires an architecture, not just a chat window.

OPA: the mental model that makes it click

I describe the approach as OPA: Orchestrate, not Prompt and Answer. The distinction matters.

In prompt-and-answer mode, you are the orchestrator. You come up with the task, you tell Claude what to do, Claude does it, you evaluate the output, you decide what comes next. Every loop requires you. You are the connective tissue, and there is a hard ceiling on how many loops you can run in a day.

In orchestrate mode, Claude is the orchestrator, or at least a co-orchestrator. Claude knows the project goals, the constraints, the open items, the history of decisions. When you sit down, you are not starting from zero and directing traffic. You are reviewing what the agent knows and either approving its next move or correcting its understanding. The cognitive load is completely different.

Getting to orchestrate mode requires Claude to have enough structure around it that it can actually hold a coherent picture of a project over time. That structure is what the rest of this post covers.

The skill system: 435 reusable procedures

The single most valuable thing I have built is a library of skills. Currently 435 of them, organized into a hub, with a registry file Claude reads to know what exists.

A skill is not a prompt template. It is closer to a procedure specification. Each skill lives in its own folder and contains three files:

• SKILL.md — the instructions, input/output contract, edge cases, and handoff points
• FUNCTIONS.md — pure functions and atomic steps that can be run independently or handed off to a Lambda
• LESSONS.md — corrections and learnings from actual production use

This file triad is the minimum viable unit. A skill without LESSONS.md is untested knowledge. A skill without FUNCTIONS.md is a narrative that cannot be executed reliably. All three together give you something Claude can invoke consistently across sessions.

The scope is broad by design. There are skills for generating estimation workbooks, skills for setting GitHub secrets without credential exposure, skills for running test loops with local Ollama models as the repair engine, skills for wiring Stripe into three different SaaS apps simultaneously. The depth is the point. A shallow skill that Claude interprets differently every time is worthless. A fully-specified skill that Claude executes identically every time is infrastructure.

When I start work on a task, the first question is whether a skill already exists for it. Usually one does, or something close enough that adapting it takes five minutes. When nothing exists, building a new skill is often the first deliverable, because the second time I need that procedure, it will cost me nothing.

Four-layer memory architecture

The skills handle procedures. Memory handles state. They are different problems and require different solutions.

I run four memory layers, each serving a distinct time horizon and specificity level.

Layer 1: In-session context. This is the current conversation window. Claude knows what we are working on right now, what files we have read, what decisions we have made this session. It resets when the session ends. Everything ephemeral lives here.

Layer 2: Project memory files. Each project has a _context/ folder with structured files: DECISIONS.md for architecture choices, OPEN-ITEMS.md for active blockers, LESSONS.md for corrections learned the hard way, WORKFLOW.md for the current build sequence. Claude reads these at session start. They are the persistent brain for a single project.

Layer 3: Cross-project memory index. A MEMORY.md index file that Claude maintains across all projects. Not detailed notes — pointers. "Ballparker split into three repos. Settlement Scout autofill logs to the run_items database. PrevenDebt iOS build is pending." Enough that if I ask Claude about any project cold, it can give me an accurate two-sentence status without me re-explaining anything.

Layer 4: The Ollama memory server. A local Python server running on my Windows machine, compressed summaries pushed to it nightly. When Claude is doing reasoning or planning work, it pulls from this server to inject project context it would not otherwise have access to. This layer handles the gap between what fits in a Claude session and the full history of decisions across months of work.

Together, these four layers mean that context switching between projects costs me almost nothing. Claude already knows where we are. The reload tax is gone.

A real day in the system

Here is what an actual working day looks like, using real projects.

Morning starts with Settlement Scout. This is a Playwright automation that submits legal claim forms on my client's behalf, logs results to a database, and fires proactive emails when it detects non-standard information requirements that need human review before it can proceed. I check the overnight run log, review any proactive emails that went out, and handle any claim supplements where the automation flagged something ambiguous. Claude helps me triage: it reads the run log, summarizes which claims need attention, and drafts the decision for ones where the answer is obvious. I approve or correct. The whole review takes fifteen minutes for what used to take ninety.

Mid-morning shifts to Ballparker. This is an estimation tool built on seven AWS Lambdas, synced across three GitHub repos under different ownership accounts. The work is usually feature development: adding a new estimation category, adjusting the cost model for a new input type, or syncing a change from the canonical repo out to the forks. Claude knows the sync command, knows which repo is canonical, knows the cost model logic because that reasoning is captured in DECISIONS.md. I describe the change I want, Claude drafts the implementation, I review and ship.

Afternoon is often Social Butterfly. This is a NestJS and React content management platform for a marketing client with a hard Beta deadline. The work here is higher stakes: client-facing communications, milestone tracking, scope questions that need careful answers. Claude's role is different here — less execution, more drafting and memory. I tell Claude what happened in the last client call; it updates the meeting summaries file and flags any scope implications against what we have agreed to. When I need to write a status update to the client, Claude drafts it in the right tone with the right context already loaded.

Between these blocks, smaller tasks come in from the other three engagements. Because Claude holds the context for all of them, I can switch without losing my place. Five minutes on a MythicQuill auth bug. Ten minutes on a Delphina Lambda configuration question. Each one starts with Claude reading the relevant project memory and giving me a thirty-second briefing. Then we work. Then I move on.

The three failure modes and how to design against them

The system is not flawless. There are three failure modes I have learned to watch for.

Memory drift. Claude's memory files can become stale. I once had the memory index confidently claiming a fix had been deployed to production on MythicQuill when in fact it existed only in a branch that had never been merged. The lesson: never trust a memory claim about production state without verifying against the repo or the running service. Before relying on "X is fixed" or "X is deployed," I run a git command or check the live endpoint. The memory is a starting point, not ground truth.

Skill rot. Skills written three months ago against an API that has since changed will confidently give Claude wrong instructions. The LESSONS.md file in each skill is supposed to capture this, but only if I update it when I notice the drift. I run a skill linter periodically that flags skills whose source code is newer than the skill documentation — a rough proxy for "this procedure may be outdated." The lint report does not fix anything automatically, but it gives me a list of skills to review before trusting them on a new task.

Context bleed. When I am moving fast between projects, there is a risk that context from one project leaks into Claude's reasoning about another. This is rarer than I expected, but it happens. The mitigation is project-isolated sessions where possible, and a habit of explicitly anchoring Claude at the start of any session: "We are working on Ballparker. The canonical repo is X. The current open items are in Y." That thirty-second anchor prevents a surprising number of errors.

What this actually enables

The point of all this is not to make it look like I am doing more than a human can do. The point is to change where my cognitive effort goes.

Without this system, most of my time would go into coordination: remembering where things are, reconstructing context, managing the overhead of switching between projects. With the system, that overhead is handled. My time goes into judgment calls, client relationships, architecture decisions, and the work that actually requires a human to be present.

Six projects is not the ceiling. The system scales. The skills library gets better every week. The memory layers get richer as projects accumulate history. The procedures that once required my attention get encoded and become automatic.

The constraint is not capacity. It is quality of engagement. Six projects is where I can still do good work on each one. The system does not change that constraint — it just means I spend my available hours on the work that matters instead of the work of keeping track of the work.

That is the real value. Not volume. Clarity.