# One folder per client is right. The client cannot open a repo. · Stacktree

Source: https://stacktr.ee/blog/one-folder-per-client

[Skip to content](#main) [Stacktree](/)[Developers](/developers)[Agents](/agents)[Docs](/docs)[Use cases](/use-cases)[Pricing](/pricing)[Blog](/blog)[Dashboard](https://app.stacktr.ee)[Sign in →](https://app.stacktr.ee)      By [ Steve Smith ](/about) · Founder, Stacktree  ·  Last updated September 7, 2026          blog · opinion

#  One folder per client is right. The client cannot open a repo.

   A structure is spreading through agencies this year: run the business out of a repository, one directory per client, agent skills and SOPs beside them. It is a good structure and it is correct about the unit. It also stops precisely where the client starts, and most of the people adopting it have not noticed yet.

  [ Give a client an address ](https://app.stacktr.ee/?join=1)   install npx stacktree-install
Copy
     No card · 3 pages free · about a minute

##  Should an agency run client work out of a Git repo?

For making the work, yes. One folder per client gives an agent the context it needs and gives you a history of every change. For handing the work over, no. A private repo is read by GitHub accounts, and a Pages site built from one is public by default. The folder is the workshop. The client still needs a door.

## On this page

  -   01  [ The structure that is spreading ](#the-structure)
-   02  [ Why the folder is the right unit ](#right-unit)
-   03  [ The half nobody specifies ](#the-half)
-   04  [ What happens if you try anyway ](#try-anyway)
-   05  [ The same idea, pointed outward ](#outward)
-   06  [ What it looks like in practice ](#in-practice)
-   07  [ What this does not replace ](#limits)
-   08  [ The point ](#the-point)

## The structure that is spreading

 On 19 August 2026, Jordan Ross posted a description of how he thinks the better marketing agencies are now organised. Two hundred and fifty five likes, and worth reading as an architecture rather than a hot take: the agency operates out of GitHub. Every client has a folder in a repo. The AI skills, agents and workflows live in there too. Company SOPs get their own folder.

 It is not an isolated post. The same month, an operator described running a firm on forty agents split across marketing, sales, finance and operations, with every open piece of client work tracked in one place. Another described an agency that grew by handing work to an AI employee that pulled the data, built the sequences and pushed deliverables through for approval. Different scales, different levels of hype, one shared assumption: the work is produced by machines that need a filesystem, and the filesystem should be organised by client.

 Meanwhile, on 19 August, an agency asked r/nocode how to build a custom client portal, explaining that they were currently managing clients across Drive, Notion and Slack. That is the same instinct arriving from the other end of the technical spectrum. Both groups have worked out that the client is the unit. Both then hit the same wall, and only one of them can see it.

## Why the folder is the right unit

 Take the pattern seriously for a moment, because it deserves it.

 Organising by client rather than by project or by tool is the correct call, and it is more correct now than it was two years ago. Three reasons.

  - Agents are good at filesystems. A directory of context is the most reliable way to tell a model what it is working on. Point an agent at clients/acme/ and the brand rules, the last four deliverables, the tone of the account and the constraints of the business are all in scope without anyone assembling a prompt by hand.
 - Specificity is the thing being sold. The complaint clients make about AI-assisted work is that it reads like it could have been written for any business in the sector. Per-client context is the direct fix, and it only exists if there is a per-client place to keep it.
 - Everything gets a history. Version control is not glamorous, but knowing what changed, when, and against which brief is the difference between an agency and a folder of PDFs. The SOPs improve in the same repo as the work, which is how they stay true.
  None of that is the part I want to argue with. The structure is right. The problem is that it is only half specified, and the missing half is the half the client pays for.

## The half nobody specifies

 Read the posts again and notice what they describe. Ingestion, context, generation, tracking, approval. Every one of them is an internal loop. The deliverable moves from the agent to the team, and there the description ends.

 But the deliverable is not finished when the team approves it. It is finished when the client has it, can find it again next quarter, and can tell it came from you. That last stretch, from the folder to the client's browser, is doing an enormous amount of unglamorous work in these architectures, and in almost every account of them it is left as an exercise for the reader. In practice it collapses back into whatever it always was: a PDF attached to an email, a Drive link, a screenshot pasted into Slack.

 So you end up with a genuinely modern production system feeding a delivery method from 2011. The internal half is versioned, structured and per-client. The external half is an attachment with a filename ending in `_v3_FINAL`.

## What happens if you try anyway

 The obvious move is to make the repo do it. It does not work, and it is worth being specific about why rather than hand-waving.

 Giving the client the repo. Read access to a private repository is granted to a GitHub account. The client needs one, needs to accept the invitation, and then needs to operate an interface built for people who read diffs. You set out to escape a portal login and arrived at a harder login attached to a steeper interface. For a non-technical client this is not a marginal downgrade, it is a deliverable they will never open.

 Publishing with GitHub Pages. GitHub is clear in its own documentation: Pages sites are publicly available on the internet by default, even when the repository behind them is private. Private publication exists, but it requires GitHub Enterprise Cloud, and a privately published site is readable only by people with read access to the repository, which returns you to the client needing an account. The two available shapes are a public URL for confidential client work, or an account requirement. Neither is a handover.

 Wiring up a static host. This is the version that mostly works, and it is where careful agencies end up: a build step, a deploy target, a subdomain, an auth layer bolted in front because the work is confidential. It is a real solution. It is also a small infrastructure project per client, maintained forever by the person who least wants to maintain it, and it puts a deploy pipeline between an agent finishing a document and a client reading it.

 The common failure in all three is a category error. A repository is a system of record for things that change and need history. A deliverable address is a system of presentation for things that are finished and need to be read. Asking one to be the other produces either an exposed URL or an account requirement, every time.

## The same idea, pointed outward

 Here is the reframing that makes the missing half obvious. One folder per client is an inside-facing structure. What it implies, and what almost nobody builds, is the outside-facing twin: one address per client.

 Same unit, opposite direction. The folder holds sources, drafts, context and history, and is read by you and your agents. The address holds finished work only, is read by the client, and contains nothing they should not see. The folder is versioned. The address is current. The folder is private by permission. The address is private by being unguessable and gated.

 An agency organised by client on the inside and disorganised at the handover has built half a structure. The tell is that the client's experience of a well-run, agent-native agency is identical to the client's experience of a chaotic one: an email with a file on it.

 Plain disclosure before the next section, since it is the part where we describe our own software: this is Stacktree's blog, and Stacktree is the outside-facing half of this argument. Weigh it accordingly, and note that nothing below asks you to change the inside half at all.

## What it looks like in practice

 Keep the repo exactly as it is. Add one step at the end of the pipeline.

 When the agent finishes a deliverable, it publishes the HTML and names the client in the same call. The [client space](/client-spaces) is created on first use, so there is no setup call and nothing to keep in sync with your folder names. The page becomes a private address, and it joins everything else published for that client at one permanent address, newest first, with dates.

 Point `acme.youragency.com` at that space and it is your domain in the client's address bar rather than ours. Under a verified parent domain there is no per-client DNS to do, which matters when the twentieth client arrives. Put a [passcode](/password-protect-html-page) or a restriction to the client's company email domain on the space, and every page under it inherits the gate: the client passes it once and that browser stays in for thirty days. No account, no invitation, no seat on your invoice.

 The agent-side loop is the part that matters for a repo-first agency. From [Claude Code](/claude-code), [Codex](/codex), Cursor or any other MCP client, an agent can list what it has already published for a client, read a page back, revise it, and update it in place at the same URL. Revision in place is what stops the client accumulating four links and reading the wrong one. The link you sent in March is still the link, and it still shows the current version.

 Filing pages under a client is free on every plan, including the free one, because grouping your own work should not be a paid feature. The paid unit is the address: Solo at $19 a month includes one activated space, Studio at $79 includes ten and Firm at $249 is unlimited. Clients are never seats, so a space costs the same whether one person at Acme opens it or nine do.

## What this does not replace

 The boundary is worth stating plainly, because the whole argument is about keeping two systems distinct.

 This is not version control and it should not be treated as one. There are no branches, no diffs, no pull requests, no history of the sources. Your repo remains the system of record, and if the repo and the published page ever disagree, the repo is right. Source files belong in the folder and nowhere else. A published page is a rendered artefact for a reader, not a backup and not a distribution channel for your working files.

 It is also not a portal suite. No file collection from the client, no e-signatures, no invoicing, no payments, no messaging, no project management. If the login in your workflow is genuinely earning its keep on any of those, keep the portal you have. Plenty of practices run all three: the repo for production, a suite for paperwork, and an address for the work itself.

## The point

 The agencies moving into repos have got the hard part right. They worked out before most of the market that the client is the unit of organisation, that agents need per-client context to produce anything worth sending, and that the work should carry a history.

 Then they stopped at the edge of their own network. The last hop, the one the client actually experiences and the only part of the system they will ever form an opinion about, is still an attachment.

 One folder per client on the inside. One address per client on the outside. The second one is not a smaller version of the first, and it is not the repo with the permissions loosened. It is the other half of the same idea, and it is the half your client is paying to see.

       Keep the repo. Add the address.

 Your agent publishes the finished deliverable and names the client in the same call. It lands at acme.youragency.com behind one passcode, and revisions replace it at the same URL. Filing work under a client is free on every plan.

  [ Give a client an address →
](https://app.stacktr.ee/?from=blog_cta_one_folder_per_client&join=1) Free to try: 3 pages, each live for 7 days. Own domain from $19/mo.
FAQ

## Frequent questions

     Should an agency run client work out of a Git repo? +  For production, it is a good idea and getting more sensible as agents do more of the work. One folder per client gives you version history on everything, a diff when something changes, and a fixed place for the per-client context an agent needs to do useful work: the brand rules, the past deliverables, the account notes, the SOPs. What it does not give you is a way to hand the result to the client, because the repo is where the work is made rather than where it is read.   Can I give a client access to a private GitHub repo? +  Technically yes, and in nearly every case you should not. Read access to a private repository is granted to a GitHub account, so the client has to have one, accept an invitation, and then navigate an interface designed for people who read diffs. You have replaced a portal login with a harder login and a steeper interface. If the client is not a developer, the repo link is worse than the portal invite you were trying to escape.   Can I use GitHub Pages to deliver client work? +  Only if you are comfortable with it being public. GitHub documents that Pages sites are publicly available on the internet by default even when the repository behind them is private. Publishing a Pages site privately requires GitHub Enterprise Cloud, and a privately published site is then readable only by people with read access to the repository, which puts you back to the client needing a GitHub account. So the two options are a public URL for private client work, or an account requirement, and neither is the handover you wanted.   How should agencies organise client files so AI agents can use them? +  The pattern people are converging on is one directory per client holding the context an agent needs, with shared skills and SOPs in their own directory beside it. It works because agents are good at filesystems and because per-client context is what stops output reading like it was written for any business in the sector. Keep doing that. Treat the question of how the client receives the finished thing as a separate problem, because it is one.   What is the difference between a client folder and a client space? +  They are the same idea pointed in opposite directions. The folder is the inside: sources, drafts, context, history, everything the work is made from, versioned. The space is the outside: one address per client holding the finished deliverables, gated once, on your domain, with nothing in it the client cannot read. An agency that is organised internally by client and disorganised at the handover has built half the structure.   Do I still need a client portal if the work lives in a repo? +  You need whatever the relationship actually contains. If clients upload documents, sign things or pay inside the same system, a portal suite is the right machinery and the repo does not replace it. If the client only receives finished work, you do not need a portal and you do not need the repo to become one. You need an address the client can open. We wrote the longer version of that argument in why clients never log into your portal.   Can an AI agent publish straight into a client space? +  Yes. Any MCP client, Claude Code, Codex, Cursor and the rest, can publish a page and pass the client name in the same call. The space is created on first use, so there is no setup step and no separate configuration to keep in sync with the folder structure. The agent can also list what it has already published for that client and read a page back before revising it, which is what makes revision-in-place work rather than accumulating v2, v3 and v4 links.   Where should source files live if deliverables live somewhere else? +  In the repo, and only there. The published page is a rendered artefact for a reader, not a backup and not a distribution channel for your working files. Keeping the boundary clean is the point: version control holds everything that has a history, the client address holds the current state of everything finished. If those two ever disagree, the repo is right.
Keep reading

## Related guides

   -  [ Client spaces The outside-facing twin of the client folder: one address, one gate, your domain. ](/client-spaces)
-  [ Clients never log into your portal The companion argument: why delivery never earns an account, and when a portal genuinely does. ](/blog/clients-never-log-into-your-portal)
-  [ Agency AI deliverables The agent produced it. What it takes to deliver it under your name instead of a vendor’s. ](/agency-ai-deliverables)
-  [ Your own domain Parent-domain verification, so client twenty does not mean twenty DNS records. ](/custom-domains)
-  [ Publish over MCP The tool surface an agent uses to publish, list and revise work for a named client. ](/mcp-publish-html)
-  [ Stacktree in Claude Code The repo-first case: finish in the terminal, publish without leaving it. ](/claude-code)
-  [ Client feedback loop Comments left on the page itself, read back by the agent that wrote it. ](/client-feedback-loop)
-  [ Pricing Filing under a client is free. The paid unit is the address, not the client. ](/pricing)

References

## Sources and further reading

   -  [ GitHub Docs: changing the visibility of your Pages site ↗ GitHub’s own statement that Pages sites are public by default even from a private repository, and that private publication needs Enterprise Cloud plus repository read access. ](https://docs.github.com/en/enterprise-cloud@latest/pages/getting-started-with-github-pages/changing-the-visibility-of-your-github-pages-site)
-  [ GitHub Docs: adding outside collaborators ↗ Repository read access is granted to GitHub accounts, which is the account requirement a client link inherits. ](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/adding-outside-collaborators-to-repositories-in-your-organization)
-  [ Jordan Ross on agencies running out of GitHub ↗ 19 August 2026, 255 likes: one folder per client, AI skills and workflows in the repo, SOPs in their own folder. The architecture this post agrees with. ](https://x.com/jordan_ross_8F/status/2090117465741127890)
-  [ r/nocode: building a custom client portal for an agency ↗ 19 August 2026: an agency running clients across Drive, Notion and Slack, asking how to build the handover layer. The same wall from the other end. ](https://www.reddit.com/r/nocode/comments/1vsky0t/what_is_the_best_way_to_build_a_custom_client/)
-  [ r/agency: how client reporting actually works ↗ A research thread on agency reporting workflows where report opens, not report production, is the metric people keep returning to. ](https://www.reddit.com/r/agency/comments/1vkvnhu/how_does_client_reporting_actually_work_at_your/)

##  One folder per client. One address per client.

 Keep your repo. Publish the finished work to a private address on your own domain, gated once, revised in place. Free to try; the address starts at $19 a month.

 [
Sign up free →
](https://app.stacktr.ee/?join=1&from=cta_blog_one_folder_per_client)   install npx stacktree-install
Copy
       Private hosting for the HTML your agents make.

[](https://betalist.com/startups/stacktree?utm_campaign=badge-stacktree&utm_medium=badge&utm_source=badge-featured)[Featured on](https://devhunt.org/tool/stacktree)[](https://buildlist.io)[Get started free](https://app.stacktr.ee/?join=1)

## Product

- [Example deliverables](/examples)
- [Custom domains](/custom-domains)
- [Client feedback](/client-feedback-loop)
- [One-time links](/one-time-view-links)
- [See how pages get read](/page-engagement)
- [Made with Stacktree](/made-with)
- [Security](/security)
- [Watch the demo](/demo)

## Agents

- [All integrations](/agents)
- [Claude Code](/claude-code)
- [OpenAI Codex](/codex)
- [Cursor](/cursor)
- [Claude.ai connector](/claude-ai-connector)
- [MCP server](/mcp-publish-html)
- [Deploy from Claude Code](/deploy-html-from-claude-code)
- [Skills](/skills)
- [Slack app](/slack)
- [n8n node](/n8n)
- [Agent payments (x402)](/x402)

## Alternatives

- [All comparisons](/alternatives)
- [Head-to-head comparisons](/compare)
- [Tiiny Host](/tiiny-host-alternative)
- [GitHub Pages (private)](/github-pages-private-alternative)
- [Vercel](/vercel-alternative-for-agents)
- [ngrok](/ngrok-alternative-for-html)
- [Display.dev](/display-dev-alternative)
- [Static.app](/static-app-alternative)
- [OpenAI Codex Sites](/openai-codex-sites-alternative)
- [here.now](/here-now-alternative)
- [Shippage](/shippage-ai-alternative)
- [Best private hosting](/best-private-html-hosting)

## Use cases

- [All use cases](/use-cases)
- [Share with clients](/share-with-clients)
- [Send a file to a client](/share-html-file-with-client)
- [Share Claude artifacts](/share-claude-artifacts)
- [Share Jupyter notebooks](/share-jupyter-notebook-html)
- [Host Storybook privately](/host-storybook-privately)
- [Architecture diagrams](/share-architecture-diagrams)
- [AI-generated reports](/host-ai-reports)
- [Internal HTML tools](/internal-tool-hosting)
- [Private HTML hosting](/private-html-hosting)
- [Vibe-coded page hosting](/vibe-coding-hosting)
- [Leave a website builder](/website-builder-migration)

## Learn

- [Blog](/blog)
- [Glossary](/glossary)
- [FAQ](/faq)
- [Agent-loop hosting](/agent-loop-hosting)
- [Why agents need a publish primitive](/blog/why-agents-need-a-publish-primitive)
- [MCP servers explained](/blog/mcp-servers-explained-for-developers)
- [What changed in the 2026-07 MCP spec](/blog/mcp-2026-spec-changes)
- [Sites in Codex explained](/blog/sites-in-codex-explained)
- [Private-by-default hosting](/blog/private-by-default-html-hosting)
- [An agent paid us $1 (x402)](/blog/agent-paid-to-provision-itself)
- [When a loop hits a paywall](/blog/loop-engineering-paywall)
- [Pricing](/pricing)
- [Self-host (new)](/self-host)
- [Changelog](/changelog)
- [Docs](https://stacktr.ee/docs)
- [About](/about)
© 2026 Stacktree · stacktr.ee

[Privacy](/privacy)[Terms](/terms)[Security](/security)[Dashboard](https://app.stacktr.ee)[npm](https://www.npmjs.com/package/stacktree-mcp)[Sitemap](/sitemap.xml)[llms.txt](/llms.txt)[API spec](/openapi.json)

---
Full markdown summary of the Stacktree marketing surface: https://stacktr.ee/llms-full.txt