Client Demo Checklist: Localhost Without Surprises
Demos fail for boring reasons
Not because your code broke — because the tunnel was not running, the URL changed, or the client hit an interstitial page nobody warned them about.
This checklist takes five minutes and prevents the embarrassing "give me a second" moments.
Why preparation beats improvisation
Client demos fail in predictable ways: the developer shares localhost:3000, the tunnel was started before the app finished compiling, or the OAuth login redirects to a URL that only works on the developer's machine. None of these are code bugs — they are workflow gaps.
Treat the tunnel URL like a production deploy artifact for the duration of the call. Generate it after the app is healthy, verify it yourself, then share it. The five minutes upfront cost less than credibility lost mid-presentation.
Before the call
npm run dev
npx localtolink
- App loads locally at
localhost:PORT - Tunnel URL loads in your browser (not just localhost)
- Test login flow with test credentials seeded
- Hard refresh confirms latest code is showing
- QR code scanned on your phone if mobile matters
- Note session start time — free tier lasts 2 hours
- Copy URL to clipboard before the call starts
Environment checklist (technical)
Beyond the tunnel itself, confirm dependencies your demo touches:
-
.envhas test API keys — not production secrets - Third-party sandboxes (Stripe test mode, Twilio test credentials) are active
- Database migrations applied locally so UI matches expected schema
- Background jobs or websockets your feature needs are running
- Browser extensions disabled if they inject scripts into your app
Run through the happy path once end-to-end through the tunnel URL, not localhost. OAuth redirects and cookie domains behave differently on the public URL.
During the call
- Send HTTPS URL, not localhost
- Mention first visit may show a brief warning page — click Continue once
- Keep terminal with tunnel open — closing it kills the link
- If you hot-reload breaking changes, warn client to refresh
If something breaks live
| Issue | Quick fix |
|---|---|
| Blank page | Check dev server still running; restart app |
| 404 | Wrong path — verify route exists |
| Tunnel dead | Restart npx localtolink; send new URL |
| Slow load | Normal — traffic routes through tunnel hop |
| Client VPN blocks | Try phone on cellular |
After the call
- Stop tunnel (Ctrl+C) — link goes offline
- Note any provider URLs to update if you restart later
What not to demo through a dev tunnel
- Production data or real customer accounts
- Flows requiring your laptop to sleep mid-call
- Multi-day review links (URL expires; machine must stay on)
Recovery script when the demo breaks
If the tunnel dies mid-call, say this once and execute:
- "The preview link refreshed — I will send an updated URL in chat."
- Restart
npx localtolinkin the terminal you kept visible - Paste the new HTTPS URL — do not debug silently for more than 30 seconds
- Client hard-refreshes once
Clients forgive infrastructure hiccups when you communicate clearly. They do not forgive unexplained silence while you troubleshoot.
Post-call follow-up template
Send within an hour of the call:
Thanks for the review today. Summary of changes we discussed: [bullet list].
Next steps on my side: [tickets or dates].
The preview link is now offline. I will send a staging link when [milestone].
Professional closure reinforces that the tunnel was a deliberate preview channel, not a flaky production environment.
Time-boxing the tunnel session
Free tier sessions last two hours. For a scheduled 30-minute call, start the tunnel five minutes before — not at the beginning of your workday. You preserve session time for the actual demo and reduce the chance of mid-call expiry on back-to-back meetings.
If the call runs long, glance at the terminal expiry timestamp LocalToLink prints. Restarting takes ~10 seconds; sending the new URL proactively beats a surprise outage.
FAQ
Should I deploy to staging instead?
For formal UAT or multi-day reviews, yes. For same-day WIP feedback, a tunnel is faster.
Can I record the session?
Yes. Screen share your local app via the tunnel URL or share localhost in the recording tool.
What if the client wants the link after the call?
Explain that dev preview links are session-based. Offer a staging deploy or schedule a follow-up while your machine and tunnel remain active. Do not promise a permanent URL from a free-tier tunnel.
Should I share the tunnel URL in public Slack channels?
Only if the app contains no sensitive data and you trust channel membership. Prefer DMs or password-protected meeting chat. Stop the tunnel immediately after the call.
Next steps
Try it now
Start a tunnel from your project directory — no account required.
$ npx localtolink