Stop Running a Staging Server Just to Show a Client Your Work

McKittrick — Thu, 19 Mar 2026 09:58:57 +0000

Let me paint a picture you might recognize.

You're a freelancer or agency dev. You've built something locally. It looks good. You want your client to see it – not a screenshot but an actual live thing they can click around in and add comments or approve it.

So what do you do?

If you're lucky, there's a staging server already running. Someone set it up. Someone maintains it. Someone pays for the hardware. There's a deployment process, probably some SSH config, maybe a Jenkins job or a half-documented script that only works on Dave's machine. You push your code, wait, debug why it didn't deploy, fix it, wait again.

If you're unlucky – which is most of the time – you're the one who has to set all of that up first.

The hidden cost of on-premise staging

On-prem staging sounds boring, but the real cost is brutal when you add it up:

Hardware – servers that run 24/7, mostly idle
Maintenance – OS updates, security patches, "why is nginx down again"
People – Ops, DevOps, or the dev who gets pulled off actual work to keep it running
Complexity – every new project means new config, new setup, new potential for something to break

For larger teams this gets absorbed somewhere in the org. For freelancers, solo devs, and smaller agencies it's just pain. You either over-invest in infrastructure that feels absurd for the actual use case, or you cobble something together that barely works.

And all of this just to show a client a feature that took two hours to build.

The actual use case is stupidly simple

Think about what you actually need in 90% of cases:

"I have something running locally. I want a URL I can send to a client right now."

That's it. Not a permanent environment. Not a CI/CD pipeline. Not a Kubernetes cluster. Just a live, shareable URL for the thing currently on your machine.

30 seconds. One command.

I've been using prev.sh for this and it genuinely changed how I handle client reviews.

From your project folder:

bash$ prev deploy .

That's it. Under 30 seconds later you have a live URL you can send to anyone. They open it in a browser, click around, give feedback. When you're done, the environment gets cleaned up automatically.

No server to maintain. No SSH config. No deployment pipeline to babysit. No Dave.

Who this actually makes sense for

If you're at a large company with a dedicated DevOps team – fine, you probably have this solved already.

But if you're:

A freelancer who needs clients to review work before billing
A small agency where every hour of overhead directly hits your margin
A solo dev who just wants to show something without spinning up infrastructure

...then spending time and money on a staging server for this use case is genuinely hard to justify when the alternative is a one-liner.

But there's more than just a URL

Once you're past the one-liner, prev actually has a proper dashboard behind it – and it's genuinely useful, not just a vanity feature.

What you get:

Environments view – all your running previews at a glance: status, region, TTL, expiry countdown. Extend the TTL with one click if a client review runs long.

Feedback Inbox – this one surprised me. Clients can leave feedback directly on the preview page, flagged as Approved or Changes Requested. No more chasing feedback through email threads or Slack messages.

Container Logs – stdout and stderr, live, right in the browser. Useful when something behaves differently in the preview than locally.
Deployment History – every past environment is archived and can be redeployed with one click. Handy when a client comes back two weeks later asking to see an old version.

Managed Databases – spin up a PostgreSQL, MariaDB or MongoDB instance and attach it to your preview via --db. For projects that need more than a static frontend.

Webhooks & Notifications – get notified on Slack, Discord, Teams or via email when a preview is deployed or when feedback comes in.

Deployment Templates – save your usual config (region, TTL, auth, database) as a named template and reuse it with --template name. No more typing the same flags every time.

Built-in Support Chat – got a question while you're setting things up? There's an AI support chat directly in the dashboard. No docs-diving required.

Feature Requests – missing something? There's a built-in feature request form. No UserVoice account, no GitHub issue template – just type and submit.

Curious whether this fits your workflow – drop a comment if you've been dealing with the same staging headaches, or if you're solving it differently. Always interested in how other devs handle client reviews.