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. Every plan shows opens and unique viewers, 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. On every plan 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; pricing has the full breakdown.
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. 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, passcode or email gate on any plan |
| 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; 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, on any plan.
- Your own domain demo.yourstudio.com instead of a vendor URL. Solo includes one, Studio ten.
- 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 →