A practical guide to structuring client folders, shared systems, and automation so that onboarding each new client costs roughly the same as the second.
Adapted from @Kenny_GTM# How to Build a Services-as-Software Delivery Stack I have 15 client folders open in my terminal right now. Opening the 15th cost me about what the 2nd did, and that single fact is the whole difference between a services-as-software company and an agency paying for a Claude subscription. The pitch is the half everyone has heard. You price a result instead of hours, you say software does the work, the client signs. That part is easy, which is why the model spread so fast. The second half is where it comes apart, and it never comes apart loudly. It shows up as a GTM engineer asking in Slack what a client's ICP is, 4 months after kickoff. Or a scoring model getting rebuilt from memory, because the good version lives in another account and nobody remembers which one. By client 3 you are hand-building what you already hand-built for client 1, charging software prices for it, and hiring your way back into the business you were trying to leave. So here is the test. What does it cost you to open client folder 15 compared to folder 2? Roughly the same means software is genuinely doing the delivery. Anything more and you are running an agency with a much harder story to tell. At Frontal we have done this work across 275 companies and the same thing is true every time: companies buy the tools and cannot make them run. The 6 systems below are what keep folder 15 cheap. Worth building at 2 clients, and at 15 there is no business without them. By the end of this, you'll know: 1. The 1 file that lets someone take over a client account in minutes instead of asking 3 people what the ICP is 1. What to keep isolated per client and what to share across all of them, and why cross-client bleed is the hardest bug to spot 1. The procedures worth writing once, including the scoring model that removes roughly 80% of manual sorting 1. Which 4 jobs still need a human, and the 1 workflow you should never put inside a folder None of this needs a developer. It does need your own API keys, and something will break on the first run of every build. That is the honest boundary. The rest is copyable as written. A note on the order. Each system has a client number on it. That is roughly the point where not having it starts costing you real hours. Build them in sequence and you pay for each one just before you need it. # 1. The folder boundary Starts costing you at: client 2. 1 folder per client. Its own context, its own API keys, its own history. Nothing crosses between them unless I move it across on purpose. This is the boring one and nobody wants to start here. Start anywhere else and you will spend a month debugging the wrong layer. Inside each folder I use the WAT structure. Workflows are markdown instructions. The agent is Claude Code. Tools are the scripts that execute actions. 3 folders, and every new file has an obvious home. At the root sits CLAUDE.md. This is the system prompt for the project. Without it Claude is generic. With it, Claude is an expert in that client's workflows, tools and data. (http://claude.md/) Keep it under 200 lines. I have spent 600+ hours inside Claude Code and that cap is the single rule I have never regretted setting. Past 200 lines it stops working as a system prompt and turns back into a document, and nobody reads documents properly, including the model. I decide what earns a place in those 200 lines before I build anything else in the folder. Whatever does not fit has to live somewhere on purpose, which is what the next 2 systems are for. What breaks without it: client 2's positioning turns up in client 1's copy and nobody notices for a week. There is no error message for this. The output reads clean and is just wrong. # 2. The per-client context file Starts costing you at: person 2 on the account. Every client gets a context.md. ICP, offer, personas, what is working, what is not. (http://context.md/) Before we built this at Frontal, we had normal agency chaos. Good ideas lived in Slack. Copy wins were shared in our #random channel, literally. Research stayed in 1 person's head. New hires relearned old lessons. With per-client context files, a GTM engineer picks up any account in minutes. No more "let me check with sales" for basic context. 1 rule matters more than the file itself: rank your sources. The ICP doc, the intelligence store and last quarter's campaign notes will eventually disagree with each other. Decide which one wins before an agent runs, not after it has written 40 emails on the losing one. GitHub became our source of truth for all of it. That sounds like housekeeping until output changes on an account and you can diff the context file to find out exactly why. What breaks without it: onboarding a new person costs you about as much as onboarding a new client. That is the exact cost you were trying to get rid of. # 3. The skills library Starts costing you at: client 5. Around folder 5 you notice you have written the same procedure 5 times, each version slightly different, and you cannot remember which one was the good one. That is the signal to stop and build this. A skill is an instruction file that teaches Claude how to do 1 specific GTM task. Claude loads only what is relevant to the job in front of it. I open-sourced the 15 skills we run across 70+ clients. 5 pillars, roughly 4,200 lines of methodology. The internal set is where the compounding happens: - Copywriting. Our winning cold email frameworks, written down. - TAM scoring. 80 to 100 point scoring models. - Contact enrichment. A 3-layer waterfall. - Campaign delivery. A 9-phase checklist. - Signal detection. 30 intent signals across 4 tiers. - Clay, database search and RevOps skills for every CRM we touch. 1 engineer writes the skill once and every folder calls the same copy of it. This is the first system on the list that makes folder 15 cheaper than folder 5 instead of just holding it level. Here is what one of them actually contains. The ICP skill clones a client's ICP from their closed-won customers in 6 steps: 1. Pull closed-won domains. The last 30 to 50 deals from their CRM. Domains only. These companies converted, paid and did not churn, which is better signal than any persona doc. 1. Find lookalikes. Drop the seed domains into CompanyEnrich's similar-companies API. Vector search runs across 30M+ companies and returns 50 matches per seed. 10 closed-won domains in, 500+ ranked lookalikes out. 1. Enrich with signals. Same tool, layered. Funding rounds mean new budget. Leadership moves mean a new buyer in the seat. Hiring spikes in target roles mean the team is expanding. Tech stack changes mean intent for adjacent tools. These become the relevance hooks for step 6. 1. Score and tier. Send each account through a classification prompt in Claude, using closed-won plus signal data as the rubric. Tier 1 is strong fit with an active signal. Tier 2 is strong fit, no signal yet. Tier 3 is adjacent fit, watchlist. Roughly 80% of the manual sorting goes away here. 1. Enrich contacts. CompanyEnrich, Prospeo and FullEnrich. People search across 170M+ profiles for the right titles, then a waterfall through multiple providers for verified emails. 1. Personalize per tier. 1 prompt per Tier 1 account using its signal context. Templated hooks for Tier 2 with a single variable swap. High-volume sequences for Tier 3. Outreach intensity matches the tier: call plus LinkedIn plus email for Tier 1 through Nooks, lemlist and Instantly. LinkedIn plus email for Tier 2. Email only for Tier 3. That is 1 skill, written once, called by every folder, and fixed in 1 place on the day it turns out to be wrong. # 4. The connection layer Starts costing you at: the first time an agent describes last month's pipeline back to you. MCP servers. 1 connection and Claude controls the whole tool, endpoints and parameters included. The 10 I would connect for any GTM team: Notion, Slack, n8n, HubSpot, Apollo, Instantly, Firecrawl, Fireflies, GitHub and ClickUp. At Frontal the working set across accounts is Instantly, Fireflies, Notion, Clay, Apollo and Attio. Setup is 1 line per tool. About 5 minutes each. That is the whole install cost for the layer that makes Claude Code an operating system instead of a chatbot. A few of these earn their place on day 1. With Fireflies connected, Claude can search every meeting you have ever had and pull transcripts, action items and summaries without anyone opening a recording. Instantly means launching campaigns and reading analytics from the terminal. And n8n lets Claude build, test and debug automations without you opening the UI at all. What breaks without it: the agent has all of your instructions and none of your live state. What comes out is fluent, well-structured, and describes a pipeline that stopped being true 3 weeks ago. That is much harder to catch than something that simply breaks. # 5. The data layer Starts costing you at: client 9 or so, the first time someone asks how an account is doing and the answer is a manual report. Supabase underneath everything. All TAM lists, contacts, campaigns and performance snapshots in 1 database. Campaign performance gets tracked daily on its own, so you can look at a trend without anyone pulling a report for it. The part that matters for delivery cost: every engineer queries the same data. 1 person's work becomes available to everyone else without a handoff meeting, a Loom, or a Slack thread nobody reads. Deploy the scheduled pieces to a cloud runner and pay only when they run. Trigger on a schedule or a webhook. It runs while you sleep, which is the only realistic way to get a daily snapshot across 15 accounts. Before you deploy anything here, run a security review. 1 prompt: check for exposed API keys and vulnerabilities. It takes about 30 seconds and it is the cheapest insurance in this stack. # 6. The intelligence store Starts costing you at: the moment client 10 relearns what client 3 already proved. Every campaign insight gets logged. Which copy angles worked and which did not, which personas responded best, which segments outperformed. Stored per target type, per market, per ICP. Before writing new copy, Claude checks what is already proven for that specific segment. That is the whole loop. Across the agency that store now holds 11,000 campaigns, 132,000 snapshots and 30+ clients. When 1 engineer finds a winning angle on a Tuesday, every other account can be using it by Thursday. The other 5 systems exist to stop your delivery cost climbing as you add clients. This is the only place in the stack where what you deliver gets better while nobody is working on it. # What the 6 actually buy you 500+ AI workflows across 70+ clients. 37 agents running for a $7M ARR business. Of those 37, about 6 changed how we operate day to day, and pre-call research is the clearest one: a full brief in 90 seconds that used to take a rep 15 minutes of manual digging. At campaign level it looks like this. Claude Code reads the Instantly API docs straight out of the project folder, hits the Apollo API, and pulls 153 contacts in about 90 seconds. I run those through a waterfall, Wiza then FullEnrich then Prospeo, and end up with 149 verified emails. On a full waterfall, coverage pushes past 90%. Campaign live in Instantly. Anyone can do that once, in 1 folder, on a good day. It turns into a business when the procedure was written down once and folder 15 calls the exact same copy of it. # The 4 jobs that still need a human 1. API keys. You add your own, per folder, every time. There is no version of this where that gets automated away, and you would not want one. 1. The debugging pass. Something breaks on the first run of every build. Claude will investigate the error, fix the code and update the workflow so it does not break the same way twice. You still have to be there for the first one. 1. The cut. Tiering removes roughly 80% of the manual sorting. The last 20% is a judgment call about which accounts do not deserve a send at all, and that call has revenue attached to it. 1. The call. The pre-call brief lands in Slack in 90 seconds. It does not run the meeting. # The one workflow you should not put in a folder This whole stack is built for individual-level work, and that is also where it stops. I am the only person on those 15 accounts, and that is a large part of why it holds together. Put the same 15 folders on 5 laptops with 5 operators and you no longer have a system. You have 5 people guessing which version of a skill is the current one. So keep the revenue-critical, team-level workflow out of it. If you build a RevOps flow that pulls from the CRM, checks the data is fresh and pushes updates back, that flow cannot live locally on someone's machine. It needs a monitored home in the cloud where the whole team can see what is running and what failed at 3am. Build the folder stack for work that 1 person owns end to end. Anything the whole revenue team depends on belongs somewhere they can all watch it.
