How to Demo Your Work to a Client Without Deploying It First
The client wants to see progress. Your feature is half-built, the backend is running on your laptop, and the last thing you need right now is a staging deployment. Screenshots feel dated. Screen shares are clunky. There is a better way: share a URL that opens your actual running application in their browser, live, interactive, and exactly as it exists right now on your machine. This guide shows how to do it in under two minutes using a Localtonet HTTP tunnel.
📋 What's in this guide
The Problem with Staging Deployments for Client Demos
The standard workflow looks like this: write some code, deploy to staging, fix the deployment issues that always seem to appear, send the client a link, wait for feedback, make changes, deploy again. Each round trip takes anywhere from twenty minutes to a few hours depending on your stack. For a project where the client wants to see progress twice a week, that overhead adds up fast.
There is also a quality problem. Staging environments drift. Environment variables differ. The database has different data. The third-party integrations are configured differently. What the client sees on staging is often not quite what they will get in production, and it is definitely not what is running on your machine right now as you develop.
Screenshots and screen recordings are one step removed from the real thing. The client cannot click around, cannot test their own user flows, cannot feel the actual performance. They are watching a demo instead of using the product.
Live tunnel demo
- Ready in under two minutes
- Client sees and interacts with the actual running code
- No staging drift same environment you develop in
- Works from any device and browser the client has
- Feedback is immediate and specific
- No deployment pipeline to maintain
Staging deployment
- Deployment takes time every iteration
- Environment may differ from your local setup
- Pipeline failures block demos
- Staging costs money to keep running
- Client feedback is on staging, not the real thing
How a Live Demo Link Works
A Localtonet HTTP tunnel takes your locally running application, whatever is on port 3000, 8080, or any other port and maps it to a public HTTPS URL. The tunnel client runs on your machine alongside your app, makes an outbound connection to a relay server, and any request that comes into the relay URL gets forwarded back through the tunnel to your local server.
Your client opens the URL in their browser. Their request travels to the relay, through the tunnel, to your laptop, gets processed by your local server, and the response travels back the same way. From their perspective it is a completely normal website. From your perspective it is your local dev server, running in your environment, with your database, your environment variables, and your latest uncommitted changes.
The client connects to the Localtonet relay address, not your machine directly. Your home or office IP address is never exposed. The tunnel is the only bridge between the public internet and your local server.
Set Up a Live Demo Link in Under Two Minutes
Start your local application
Make sure your app is running and note the port. A React app on port 3000, a Node.js API on port 4000, a Django app on port 8000, whatever you are building.
Install Localtonet and authenticate
# Linux / macOS
curl -fsSL https://localtonet.com/install.sh | sh
localtonet --authtoken <YOUR_TOKEN>Create an HTTP tunnel for your app's port
Go to the HTTP tunnel page,
set local IP to 127.0.0.1 and port to the port your app is running on.
Click Create and start the tunnel.
The dashboard shows a public HTTPS URL.
Send the URL to your client
Copy the HTTPS URL from the dashboard and send it over email, Slack, WhatsApp whatever you use to communicate. The client opens it in any browser on any device and sees your running application.
Stop the tunnel when the demo is over
Stop the tunnel from the dashboard or stop the Localtonet client. The URL immediately becomes unreachable. The client can no longer access your machine.
Common Demo Scenarios
🌐 Web application or SaaS dashboard
Your frontend runs on port 3000 and calls a backend on port 4000. Create one HTTP tunnel for the frontend. If the frontend calls the backend using an environment variable for the base URL, also create a tunnel for the backend and update the env variable before starting. The client opens the frontend tunnel URL and the app behaves exactly as it does locally.
🛒 E-commerce or checkout flow
Your client wants to test the full purchase flow including Stripe checkout. Stripe's redirect URLs need to be publicly reachable HTTPS addresses. Update your Stripe webhook endpoint and success/cancel URLs to use the tunnel address, run the checkout flow, and your client sees the real thing; live payment redirect, success page, and all without a single deployment.
📱 Mobile-responsive design review
The client wants to check how the site looks on their iPhone. Send them the tunnel URL. They open it in Safari on their actual phone. No emulator, no screen recording, no "it looks like this on my screen" descriptions. They see the real layout on their real device and can send you a screenshot or video of any issues they find.
🔌 API demo for a technical client
Your client is a developer and wants to test the API you built before signing off on a milestone. Create an HTTP tunnel for the API port and send them the base URL. They run their own test scripts or Postman collections against your local API and verify the contract themselves without waiting for a deployment.
🏢 Internal stakeholder review
A product manager or designer wants to click through a new flow before it goes to QA. They are in a different office or working from home. Send them the tunnel URL for the five minutes they need to review it. Stop the tunnel when they are done. No staging access to provision, no credentials to share.
Tips for a Smooth Client Demo
📋 Use seed data that tells a story
Load your local database with realistic demo data before the call.
Real-looking names, products, and transactions make the demo feel complete.
Avoid showing raw UUIDs and test_user_1 placeholder data to clients it breaks the illusion and distracts from the features you want them to evaluate.
🔗 Reserve a fixed subdomain for recurring demos
If you demo to the same client frequently, reserve a consistent subdomain in the Localtonet dashboard so the URL is the same every time. The client can bookmark it. You do not have to paste a new URL into every message. The link just works whenever the tunnel is running.
🌍 Use a custom domain for a professional impression
A URL like https://demo.yourcompany.com looks significantly more professional
than a random subdomain. Attach a custom domain to the tunnel in the Localtonet dashboard.
The client sees your brand, not a relay address, and the setup takes about ten minutes.
See the custom domain guide for step-by-step instructions.
🔄 Keep the app running in the background during the demo
If you are on a call and need to make a quick change, keep the tunnel running. Restart your dev server with the change, the tunnel reconnects automatically, and the client can refresh the page to see the update. Live code changes during a review call are a powerful way to address feedback instantly.
🧹 Clean up after the demo
Stop the tunnel when the session is over. If you used real or sensitive data, clear the database or revert to your normal dev seed. Tunnels are for temporary sharing they should not stay running indefinitely when you are not actively demoing.
Controlling Who Can See the Demo
By default, anyone who has the tunnel URL can access your application while the tunnel is running. For a quick internal review that is fine. For a client demo where you want only that specific client to have access, there are a couple of options.
🔐 Add SSO authentication to the tunnel
In the Localtonet dashboard, enable Single Sign-On on your HTTP tunnel. Anyone who opens the tunnel URL must log in with Google, GitHub, Microsoft, or GitLab first. Only authenticated users get through to your app. This is the cleanest option for demos where you want to restrict access to specific people.
🔑 Add username and password protection
Localtonet also supports username and password protection on tunnels. Enable it in the tunnel settings and share the credentials with your client alongside the URL. Anyone without the password sees a login prompt instead of your application. See the Username/Password SSO documentation for setup steps.
⏱ Time-box the demo window
The simplest access control is time. Start the tunnel five minutes before the demo call, run the session, and stop the tunnel as soon as it ends. The URL becomes a dead link the moment you stop sharing. For a one-hour review session with a single client, this is often all you need.
Frequently Asked Questions
Can the client interact with the app, submit forms, and create real data?
Yes. The tunnel forwards all traffic transparently; GET, POST, WebSocket, file uploads, everything. The client can click buttons, fill forms, create accounts, and trigger any interaction your application supports. All the data lands in your local database on your machine. You can inspect it, modify it, or reset it at any time.
What if my laptop goes to sleep during the demo?
If your laptop sleeps, the local server stops responding and the tunnel connection drops. The client will see connection errors. Keep your laptop awake during demos by adjusting your power settings beforehand disable sleep for external power on macOS under System Settings, or adjust the screen timeout on Windows. Some developers run demo sessions plugged into power with the screen saver disabled.
Will my home internet speed affect the demo experience?
Your upload bandwidth is the limiting factor. The client's request comes in, gets processed locally, and the response goes out through your upload connection. For a standard web application with HTML pages and API responses, even a modest home broadband connection is fine. Large file downloads or video streaming from your local server would be more sensitive to upload speed.
My app calls third-party services that need a public callback URL. Will those work?
Yes. This is one of the main advantages of a live tunnel over screenshots. If your app uses OAuth login, Stripe payment callbacks, or any other service that redirects back to a URL, configure those callback URLs to use your tunnel address. The redirect lands on the relay, gets forwarded to your local server, and the full flow completes. Just remember to update those callback URLs back after the demo session.
Can multiple clients access the demo at the same time?
Yes. Multiple people can open the tunnel URL simultaneously. Each gets their own connection to your local server, handled as separate HTTP sessions. Whether multiple concurrent connections cause any issues depends on your application's ability to handle them, not on the tunnel itself.
Is this suitable for showing a WordPress or other CMS site?
Yes. If WordPress is running locally; MAMP, WAMP, LocalWP, or plain Apache create an HTTP tunnel for port 80 or 8080. One extra step: update the siteurl and home values in WordPress's database (or in Settings → General) to use the tunnel URL instead of localhost. Otherwise WordPress generates internal links pointing at localhost, which the client cannot reach. Revert this setting after the demo.
Share Your Work Live | No Deployment Required
Create a free Localtonet account, start your app, open an HTTP tunnel, and send the URL. Your client is looking at your live application in under two minutes.
Create Free Localtonet Account →
