Why "one folder per client" breaks down fast in ChatGPT
The instinct makes sense: give each client their own folder, or their own ChatGPT project, and keep everything separate. It works for the first few clients. Then two things start happening at once.
First, the shared parts multiply. Most of what you write for Client A and Client B is the same tone rule, the same formatting instruction, the same output format, copied into each client's folder because ChatGPT's folders don't talk to each other. A fix to that shared rule means opening every client folder and editing each one, and it's easy to miss one.
Second, the boundary gets fuzzy. Without a structural wall between clients, it's not hard to paste the wrong brief into the wrong chat, especially late in the day with six tabs open. A folder is a naming convention, not an enforced boundary. It relies entirely on you remembering which chat is which.
Three ways people currently organize prompts by client, and where each falls short
Most people land on one of three approaches before looking for something better.
A doc or spreadsheet per client works as a first pass, and it's the easiest to start. The problem shows up the same way it does for any shared library: nothing connects the entries, so a shared rule that applies to five clients has to be pasted into five separate docs and maintained in five places.
Chat history as the archive means scrolling back through old conversations to find "the prompt I used last time." It works until you have more than a handful of clients or more than a few weeks of history, at which point finding the right message costs more time than writing a new one from scratch.
Custom GPTs per client come closest to a real structure, since each one holds its own instructions. But a custom GPT's instructions are one block of text, not composable pieces, so updating a shared rule across ten client GPTs means editing the instructions field in ten separate GPTs by hand.
A better structure: client workspaces, shared rules, and per-client overrides
The structure that holds up combines three pieces instead of one folder.
A separate workspace per client keeps that client's material contained. In PAL, that's a Project: an archive-and-restore-capable container that acts as the boundary, so what belongs to Client A doesn't sit next to Client B's material by accident.
Shared rules live once, outside any single client's workspace. A tone guide or formatting standard that applies to every client is a Blend at global scope, referenced from inside each client's Project rather than pasted into each one. Edit the global version, and every Project that references it picks up the change the next time it's used.
Per-client overrides live inside that specific client's Project. When one client genuinely needs something different, a stricter tone or an extra formatting rule, that difference is a Blend scoped to their Project, not a duplicate copy of the shared rule with a few words changed.
Finding things stays manageable as the client count grows, because search, filters, favorites, and archive apply inside each Project, so a workspace with forty Blends in it is still navigable the same way a workspace with five is. Pin the handful of Blends you touch every week, and the rest of the library stays searchable without cluttering the view you actually work from.
Step-by-step: setting this structure up
Start with the shared parts. Before touching any single client, write your tone rule, formatting standard, and any other instruction that genuinely applies everywhere as a global Blend. This is the piece you'll reference from every client from now on, so it's worth getting right before client-specific work begins.
Create a Project for each client. Each one is a contained workspace: everything specific to that client, from briefs to generated output, lives inside it and nowhere else.
Reference the shared Blends from inside each Project instead of copying them. Where a client's work needs the tone rule, point to the global Blend rather than pasting its text in. That reference is what makes the later "fix it once" behavior work at all.
Add overrides only where they're actually needed. Most clients won't need one. When a client does need something different, add a project-scoped Blend for that specific exception, and leave the global rule untouched for everyone else.
Keeping it organized as you add clients
The structure doesn't get harder to maintain as the client count grows, because the shared parts don't multiply with it. Client fifty references the same global rules client one does, and a fix to those rules reaches every client the moment you generate again, not after a pass through fifty separate folders.
None of this locks you into one model either. Nothing in PAL calls a model's API directly, so the same client-workspace structure works whether you're pasting output into ChatGPT, Claude, or Gemini for a given task, and switching which model you use for a particular client doesn't mean rebuilding anything.
For a working example of exactly this shape, base rules plus per-client overrides, the multi-client assistant base in the gallery is a real system you can open and clone rather than a description of one. And if you haven't yet set up the underlying pieces this structure depends on, Blends, scope, and how they connect, How to Organize AI Prompts and What Is a Reusable Prompt System both cover that ground in more depth.