Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
One folder per client is the right structure for making the work. It stops at the point where someone outside the studio has to open it — and that half tends to go unspecified until the day you need it.
Worth taking seriously before poking at it, because the structure is correct about the thing it is correct about.
Agents work well against a filesystem. 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 previous deliverables, the tone of the account and the constraints of the business are all in scope without anyone hand-assembling a prompt.
Specificity is what you are selling. The standard complaint about AI-assisted work is that it reads like it could have been written for any business in the category. 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. Knowing what changed, when, and against which brief is the difference between a revision and an argument.
None of that is in dispute here. The question is what happens at the end.
The structure describes how work is produced. It says nothing about how it is received, and the two have almost opposite requirements.
| The workshop | The handover | |
|---|---|---|
| Who opens it | you, your team, your agents | one client contact, maybe two |
| What they need to see | everything, including the mess | one finished artifact |
| Acceptable friction | high — it is your tooling | close to zero |
| Access model | account-based, persistent | knowing the URL |
| Lifespan | as long as the account exists | this review cycle |
Every row points a different direction. That is why the folder cannot also be the door — not because the folder is badly designed, but because it was designed for the other column.
This is the first thing most people try, and it is worth being precise about why it disappoints.
The account is a real wall. A private repo is read by GitHub accounts. For a developer that is nothing. For the person who actually signs off your work — a marketing director, a founder, a compliance reviewer — "create an account on a code hosting platform" is where the review stops. The deliverable does not get seen, and the feedback you needed does not arrive. That is not a client being difficult; you handed them a tool built for a different job.
The permission shape is wrong, not just heavy. Repo access grants the repo. The client who should see this quarter's landing page can read every commit message, every abandoned draft, and — if you really do run one repo with a folder per client — potentially other people's folders. There is no per-artifact door in that model, so the only safe fix is to split repos, which fights the structure you adopted on purpose.
"Just look at the PR" ends conversations. We wrote this up in more depth when comparing the actual options for a generated HTML file — see where to put HTML that Claude Code generated, which scores six hosts against what a non-technical reviewer needs.
Sometimes yes. Check three things before you send the link.
The longer version of this trade — including the cases where Pages is clearly the right answer — is in GitHub Pages vs a private link.
Drop the built HTML file in and send the link. Your client opens it in a browser, with no GitHub account and no repo in sight.
Small, and easy to under-build because it feels like it should be part of something bigger.
Take the finished artifact out of the workshop. Usually one self-contained HTML file — a report, a deck, a prototype, a dashboard view with the JavaScript inlined. If the deliverable is genuinely multi-file, a zip bundle that gets served as a site does the same job.
Give it an address a browser can open. No account, no install, works on the phone they are holding in a taxi. This is the whole door.
Keep the address stable across revisions. This one is worth being deliberate about, because it is invisible until it bites. Once a link is in an email thread it may have been forwarded twice; if your next upload mints a new URL, some readers are now looking at the old version and have no way to know. Pick a host where replacing the file keeps the link. We went through the mechanics of that in replacing a published HTML file without git.
Decide how long it lives. A review link and a permanent reference are different objects. Most handovers are the first kind, and an expiry is a feature rather than a limitation — the thing stops existing when the reason for it stops existing.
On miinideck the anonymous drop is one file up to 3 MB that self-destructs after seven days, and a free account adds password and expiry controls with a 10 MB file cap and one always-on document. The relevant part for this workflow is not the numbers, though — it is that the artifact leaves the repo and arrives as a URL.
No, and if it starts to, something has gone wrong.
Version history, agent context, branches, the ability to walk away with the whole record — the repo is the only thing in this article that offers any of that, and the handover step offers none of it. Nothing here should end up as the place your work lives. It is the place a copy of a finished thing goes so that someone outside can look at it.
The test is simple: if you deleted the shared link tomorrow, would you still have the work? If the answer is no, you are using the door as a filing cabinet.
Be honest about the boundary, because sending someone a static page when they needed an application is a worse failure than making them create a GitHub account.
They need to log in and see their own data. That is an app with a database and real authentication. Vercel and Netlify are built for this and will serve you better than any link host.
They need to edit the thing, not just read it. A shared document tool is the right shape. A hosted HTML file is read-only by construction.
They need a permanent, discoverable address for the public. That is a website, and it should be deployed as one. The comparison between a private link and a public deploy is worked through here.
The deliverable is the source code. Then the repo genuinely is the deliverable, and the client is technical enough to open it. That case exists; it is just not most of them.
The handover step gets the artifact in front of the client. It does not tell you whether they read it, and it does not collect their response — those are separate problems with separate answers, and pretending one link solves all three is how tools get oversold.
It also does not make the work good. The folder does that.
Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
A .json Lottie is not a page — hand it to a client and they get a wall of numbers. What it takes to turn one into something that opens in any browser, and why the answer is smaller than the tooling suggests.
You need one page live for a webinar, a resource hub, or a campaign — not a whole website. Here's how to stand up that page from a single HTML file: a private, no-index link in seconds, with expiry, custom domain, and an honest line on where registration capture belongs.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.