Claude Projects for Consultants: One Project Per Client, Not One for Everything

I currently have eight active Claude Projects. One to help with my writing, one for WP-AutoInsight development, one for my portfolio, and five for active client engagements. None of them shares files. None of them shares instructions. Each one is set up so that when I open it on a Monday morning, Claude already knows who the client is, what stack they run, what I've decided about their problem so far, and what kind of output I want. Sometimes, even the style in which Claude answers me is different. I mean, why can’t I have Claude with personality?

Before I worked this way, I didn’t even use projects; I worked as most people do on ChatGPT for free: several conversations, files spread through, context missing most of the time, and I constantly had to calibrate Claude so he knew what we were talking about. It was worse than useless. Claude would pull the wrong voice for the wrong client, cite a stack that belonged to someone else, or produce code in a framework the current client didn't use. I was using it the way most consultants use it: as a glorified chat history.

This post is about how to actually use Claude Projects if you're a freelancer or consultant juggling multiple clients. It’s really easy: one project per client, with specific files and specific instructions, treated as working infrastructure you maintain the same way you maintain a code repo.

I'll walk through one real engagement end to end so you can see what belongs in each file and why.

What a Claude Project actually is

A Project is a self-contained workspace inside your Claude account. It has three things most people skip past:

A knowledge base where you upload reference documents. Claude reads these before every response in that project.

Custom instructions that apply to every chat inside the project. Not per message. Every message, automatically.

A 200K context window, shared across the knowledge base and the conversation itself. That's roughly 500 pages of text, which sounds like a lot until you try to fit a client's codebase, their brand guide, their last three quarterly plans, and a two-month conversation history into it.

Projects are available on Pro and Team plans. If you're still on free, this feature alone is usually the reason to upgrade if you do consulting work.

The anti-pattern: one project for everything

The default approach for most consultants and freelancers is to create one project called "Work" or "Clients" and dump everything into it. Maybe they add folders or use filenames like client-a-spec.pdf to keep things separate in their own heads.

This simply doesn't work.

First, Claude reads all the files in the project on every message. You're paying a context tax for fifty irrelevant documents every time you ask a question about one client.

Second, voice and instructions leak. If Client A wants formal English and Client B wants informal Spanish, and Client C wants professional Brazilian Portuguese, a single instruction block can't serve all. You end up hedging in the prompt every time, which defeats the whole purpose of having a project.

Third, you lose the ability to hand work off. If I ever need to let a junior consultant use the Claude Project for a specific client, I can invite them to that one project without exposing every other client's information.

One project per client. Not per service line. Per Client.

The walkthrough: a real consulting engagement

Last year I took on a consulting engagement with an e-commerce company that needed its SEO content pipeline rebuilt. The deliverable ended up being the automation pipeline you can see on my portfolio - n8n workflows, Google Search Console integration, structured WordPress drafts with human review. That's what I built for them.

But separately, inside my own Claude account, I had a project called something like Client: [Ecommerce] - SEO Pipeline that I used to think about the engagement. The production pipeline uses Claude through the API. This was a different thing: my working environment as a consultant.

The instructions file

Kept short. Half a page, tops. This one looked roughly like:

Client is an e-commerce company operating in a XXXX segment. 

Primary stack: WordPress X.YZ + WooCommerce X.YZ, n8n for automation, Google Search Console for data.

My role: external tech lead. I write recommendations,  architecture decisions, and implementation plans. I don't 
write marketing copy for them.

Voice: direct, technical, assumes an engineering reader. Match the register of the project's reference documents.

When I ask for code, default to PHP (WordPress) or JavaScript (n8n workflows). Ask before using a different language.

When I ask strategic questions, push back if the question is poorly framed. Don't just answer automatically, ask questions if I'm going against the project objectives.

Flag uncertainty. If a decision depends on information not in the knowledge base, say so before guessing.

That's it. No twenty-point list of rules. No personality prompts. No "act as a senior consultant" cosplay. Just the context that Claude can't know without being told.

The push back line is the one most people don't include and the one that pays off most. Claude's default is to answer what you asked. That’s a problem with virtually all AI models so far. For consulting work, what you ask is sometimes the wrong thing to ask, and you want a model that says so.

The knowledge base

Keep a low number of files. Never more than ten for any given client/project.

1. Engagement brief. A one-to-two page document I write at the start of every engagement. What the client wants, what they actually need (usually different), what's in scope, what's explicitly out of scope, and what the success criteria are. This is the single most important file in the project. It's what keeps Claude (and me) anchored when a conversation drifts.

2. Stack inventory. A plain text file listing every technology in the client's stack. Not a diagram. A list. WordPress 6.5 / WooCommerce 8.2 / n8n self-hosted on Hetzner / Google Search Console / Mailchimp / Stripe. When I ask Claude how to solve a problem, it doesn't suggest a Shopify plugin, because it knows this isn't a Shopify site.

3. Decisions log. A running document I update after every substantial conversation. Short entries. Decided to use n8n instead of Make because client already has n8n self-hosted and Make would be a new cost center. (2026-02-14) This prevents Claude from re-litigating decisions I already made, and it prevents me from re-litigating them too.

4. Current state notes. What exists right now in the client's system. What's broken. What's working. What's been tried before me. This can get outdated fast, so keep a routine of updating it every week.

5. Client voice sample (when relevant). For engagements where I'm writing content or documentation for the client, two or three pieces of their existing writing so the output matches their voice instead of mine. For pure tech engagements, I skip this.

6. Constraints file. Things the client cannot or will not do. "No monthly SaaS subscriptions." "Must work within existing WordPress admin, no separate dashboards." "No LLM calls that send customer PII to external services." These are the rules that shape every recommendation, and without them, Claude will cheerfully suggest solutions the client has already ruled out.

That’s it. The whole project Knowledge Base. Six files, each under five pages. If you have this well organized, you are already at the top of other professionals.

What this looks like in practice

On a Tuesday morning, I open the project and ask something like: "The client wants to add product-level meta descriptions generated by AI. They asked about ChatGPT. What should I propose?"

Claude's response isn't generic. It already knows:

The stack is WordPress + WooCommerce (so the integration path is a plugin or n8n workflow, not a standalone tool)
n8n is self-hosted (so cost per API call matters more than per-seat pricing)
The constraints file rules out sending product data to external services (so the recommendation factors in data residency)
The decisions log shows we already picked Claude via the Anthropic API for another part of the pipeline (so proposing a different provider now would fragment the stack)
The engagement brief says the success criteria include human review of every generated description (so any proposal needs a review queue)

I get a response in maybe five seconds that would take me half an hour to draft from scratch, and I don't have to re-explain the engagement to get it. That's the value of Projects done right.

Maintenance: where things can go south

Setting up a project takes an hour. Keeping it useful takes ten minutes a week.

Every Friday at the end of my work time, for each active client project, I do four things:

Ask Claude to create a resume of all work done, and update the current state notes with what changed this week
Add new entries to the decisions log (if any decisions were made)
Remove files that are no longer relevant
Update the project memory instructions (if needed)

If I skip this for a month, the project starts lying to Claude. So, the time I need to keep reminding Claude of the last decisions and work already done gets bigger.

Treat the project files like a working document, not like a set-and-forget upload.

When projects end

When a project ends, I don't delete it. I archive it, which, in practice, means I remove it from my Claude Projects list but keep the files in a local folder on my machine, named and dated.

Two reasons: First, clients come back, and when they do, I want to reload the context in about five minutes instead of reconstructing it from memory. Second, the project brief and decisions log are valuable reference material for similar future projects. When another client asks about AI-assisted SEO content, I can pull the structure of the previous engagement (not the client-specific data) as a scaffold for the new project.

This is also a good place to say something obvious that nobody says: don't upload anything to a Claude Project that you wouldn't be comfortable having processed by a third party. Anthropic has good privacy practices, but the rule for consulting work is the same as the rule for any cloud tool — if the client signed an NDA that prohibits third-party processing of their data, respect that and find a different approach.

If you have the resources for it, it’s better to use a local LLM to analyze the data than to break the contract.

The quick checklist

If you're a consultant or freelancer and you want to get this set up tomorrow:

One project per active client, named clearly
Six files per project, not forty: engagement brief, stack inventory, decisions log, current state, voice sample (if relevant), constraints
Instructions file under half a page, including one line that tells Claude to push back on bad questions
Ten minutes of maintenance per project per week
Archive at engagement end, don't delete

Do this and your context-switching cost drops from "start every chat by re-explaining who this is" to "open the project, ask the question, get an answer that already knows the terrain."

If you want help setting this up

If you're running a consulting or freelance practice and your AI tooling is chaotic (context scattered across chats, voice inconsistent across deliverables, every new client engagement starting from zero), this is the kind of thing I fix as part of embedded tech lead work. It's usually a half-day of structuring your existing client context into proper projects, plus some voice calibration work, plus whatever client-facing integration work needs to happen separately.

Reach me at me@phalkmin.me or through the contact form. Tell me how many active clients you have and how you currently manage context across them. I'll tell you whether Claude Projects will solve it, or whether the problem is somewhere else in your process.

And if you're setting this up yourself: don't start with all your clients at once. Pick the most chaotic engagement, build one project for that client, use it for a week, and then replicate the pattern for the others. Trying to migrate eight engagements in one afternoon is how you end up with eight half-finished projects and no working system.

One project, one week. Then expand.

Claude Projects for Consultants: One Project Per Client, Not One for Everything