Use case
The demo deserves better than a staging server.
Publish the demo as a private page, gate it to the client, send one URL. It opens on any device with no account, stays current as the build moves, and tells you when it was opened. No deploy pipeline, no VPN, no "can you hop on a call and share your screen".
No account for your client · No card to start · About a minute
What is the best way to host a private client demo site?
Publish the demo as a web page behind an unguessable URL and send the client that single link. The URL is never listed or indexed, so it exists only where you sent it; add a passcode or restrict viewing to the client's email domain for sensitive work. The client opens it in any browser with no account, and when the demo changes you update the page in place and the same link shows the current build.
Where client demos go to die
The work is done, and now the showing of the work becomes its own project. A staging server means auth, hosting, and a URL that looks like an incident. A preview deployment hangs off your repo and CI, mints a new URL on every push, and greets the client with a platform login the moment you try to lock it down. Screen-sharing means finding forty minutes across two time zones so the client can watch you scroll. Every one of these puts infrastructure between a finished demo and the person who paid for it.
Meanwhile the client's actual requirement is one sentence: open the thing on my laptop, ideally before the meeting, without calling IT.
One link, gated, current
Publish the demo as a page and the handoff collapses to a URL. The link is unguessable and never indexed, so it is private the way a hotel key card is private: it only exists in the hands you put it in. If the work needs more, add a passcode, or restrict viewing to the client's company email domain so a forwarded link stops at the gate. Set an expiry for the end of the pitch, or burn-after-read for a one-open reveal.
When the build moves, you update the page and the link stays the same. The thread you sent last week still opens today's demo, which ends the demo-v2-final-FINAL link archaeology for good.
From build to demo link in three steps
- Bring the demo in as a page. Ask your AI to produce it as a single HTML page, or upload the file it already gave you. Interactions, charts, and styling come along intact.
- Gate it. Passcode, email-domain restriction, expiry, or burn-after-read, in any combination the engagement calls for.
- Send the link and watch the read. From Solo up you see opens, unique viewers and when it was last opened, so you know it landed before the follow-up call.
A demo that reads like a deliverable
Serve the link from your own domain, so the client opens demo.yourstudio.com rather than a vendor URL: Solo includes one custom domain, Studio ten. From Solo you see opens and unique viewers; Studio adds time on page, scroll depth, and which sections held attention, so you walk into the review knowing whether they lingered on the new flow or bounced off the homepage. Plans run Free $0, Solo $19, Studio $79, Firm $249 per month; see what upgrading to Solo unlocks.
A demo is rarely the only thing that client sees. Publish it into a client space and the demo, the prototype that preceded it and the report that follows all sit at one address, acme.yourstudio.com, newest first, behind a single passcode the client types once. The link you sent at kickoff is still the right one at handover. Client spaces with their own address start on Solo, which includes one, with ten on Studio and unlimited on Firm; grouping work by client is free on every plan.
If what you are handing over is a report rather than a build, the same pattern applies: see sending a client report as a link. If it is a single HTML file and you want the detail on gates, revocation and large files, see how to share an HTML file with a client. For the wider handoff story, start at sharing work with clients.
Staging server, preview deploy, screen-share, or a private link
| Staging server | Preview deploy | Screen-share | Private link | |
|---|---|---|---|---|
| What the client does | Logs in, maybe over VPN | Hits a platform login or a changing URL | Books a call, watches you scroll | Opens one URL in any browser |
| Setup on your side | Hosting, auth, upkeep | Repo, CI, deployment config | A calendar slot that fits two time zones | Publish a page, send the link |
| Keeping it private | Your auth, your problem | Team login or paid protection add-on | Private, but nothing to revisit | Unguessable URL and passcodes on every plan; email gates from $19 |
| When the build moves | Redeploy, hope nothing broke | New URL on every push | Another call | Same link, updated in place |
| Did they look? | Grep the access logs | No idea | Only while you watch them | Opens and unique viewers from Solo; attention on Studio |
| How it reads to the client | staging-2.internal.dev | project-git-fix-hero-abc123.vercel.app | A meeting | demo.yourstudio.com |
Frequent questions
What is the best way to host a private client demo site? +
Does the client need an account or a VPN to see the demo? +
How is this different from a Vercel or Netlify preview link? +
What happens when the demo changes? +
Can I tell whether the client actually looked at it? +
Can the demo live on our own domain? +
Related guides
- Share a deliverable with a client The wider handoff story: proposals, prototypes, dashboards.
- Send a client report as a link The same pattern for the report handoff, not the demo.
- Share an HTML file with a client The technical version: gates, revocation, and large files.
- Password-protect a page How the passcode gate works, and which plans have it.
- Client spaces One address per client, where each demo and deliverable lands.
- Pricing Free $0, Solo $19, Studio $79, Firm $249. What sits in each.
Sources and further reading
Send the next demo as a link.
Private by default, always current, on your own domain. Free to start, no card.
Publish one free →