# Host a private client demo site, no login, no deploy · Stacktree Source: https://stacktr.ee/host-client-demo-site [Skip to content](#main) [stacktr.ee](/) [Examples](/#proof) [How it works](/#how) [Pricing](/pricing) [Security](/security) [Log in](https://app.stacktr.ee) [Publish one](https://app.stacktr.ee/?join=1) By [Steve Smith](/about) · Founder, Stacktree Last updated September 20, 2026 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". [Publish one free →](https://app.stacktr.ee/?join=1) [See pricing](/pricing) 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](/custom-domains), 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](/pricing). A demo is rarely the only thing that client sees. Publish it into a [client space](/client-spaces) 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](/send-client-report-as-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](/share-html-file-with-client). For the wider handoff story, start at [sharing work with clients](/share-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 FAQ ## Frequent questions What is the best way to host a private client demo site? + Publish the demo as a page behind an unguessable URL and send the client that one 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 if the work is sensitive. The client opens it in any browser with no account, and when the build moves you update the page and the same link shows the new version. Does the client need an account or a VPN to see the demo? + No. The link opens in any browser on any device, including the phone it gets forwarded to five minutes before the meeting. A passcode or a work-email check is the whole ceremony; nobody creates an account or installs anything. How is this different from a Vercel or Netlify preview link? + Preview deployments are built for your team, not your client: they hang off your repo and CI, the URL changes on every push, and locking one down means a platform login or a paid protection add-on. A Stacktree link is one stable URL, gated with a passcode on any plan or a verified email domain from $19 a month, with no repo or pipeline behind it. It is a handoff surface, not an environment. What happens when the demo changes? + You update the page and the link stays the same, so the thread you sent last Tuesday still points at the current build. No demo-v2 link, no "which one am I opening" on the call. Can I tell whether the client actually looked at it? + From Solo ($19 per month) you see opens and an approximate unique-viewer count, so you know the demo landed before you follow up. Studio ($79 per month) adds time on page, scroll depth, and which sections held attention. See [how pages get read](/page-engagement). Can the demo live on our own domain? + Yes. Solo ($19 per month) includes one custom domain and Studio includes ten, so the client opens demo.yourstudio.com rather than a vendor URL. Free pages carry a small "Made with Stacktree" footer; paid plans carry none. Keep reading ## Related guides - [ Publish HTML from Claude Code Add Stacktree as an MCP server and Claude Code will publish the HTML it writes to a private, unguessable URL. ](/claude-code) - [ Share a deliverable with a client The wider handoff story: proposals, prototypes, dashboards. ](/share-with-clients) - [ Send a client report as a link The same pattern for the report handoff, not the demo. ](/send-client-report-as-link) - [ Share an HTML file with a client The technical version: gates, revocation, and large files. ](/share-html-file-with-client) - [ Password-protect a page How the passcode gate works, and which plans have it. ](/password-protect-html-page) - [ Client spaces One address per client, where each demo and deliverable lands. ](/client-spaces) - [ Pricing Free $0, Solo $19, Studio $79, Firm $249. What sits in each. ](/pricing) References ## Sources and further reading - [ Vercel: Deployment Protection ↗ What locking down a preview deployment actually involves on the platform side. ](https://vercel.com/docs/deployment-protection) - [ OWASP: password storage ↗ How a page passcode is stored as a hash, never in plaintext. ](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) ## Send the next demo as a link. Private by default, always current, on your own domain. Free to start, no card. [Publish one free →](https://app.stacktr.ee/?join=1) stacktr.ee [About](/about) [Blog](/blog) [Changelog](/changelog) [Pricing](/pricing) [Security](/security) [FAQ](/faq) [Made with Stacktree](/made-with) Building with AI agents? See the [developer docs →](/developers) --- Full markdown summary of the Stacktree marketing surface: https://stacktr.ee/llms-full.txt