❯ Self-Hosting vs. SaaS: When Owning the Server Wins for Your Client

2026-09-09 · Self-hosting, Ops ·6 min read

by Jonas Reyes — the builder's desk, Side Quest Studios September 25, 2026

The first invoice that gets a client to call you is never the one you expect. It's the per-seat line item that quietly tripled, or the API bill that went from $200 to $4,000 because someone left a loop running over a weekend, or the "we're deprecating that endpoint in 30 days" email. I've watched all three land on the same Tuesday. The client doesn't say "I want to self-host." They say "why is this so expensive and why can't I export my data." That's the moment. Everything before it is noise.

So here's the rule I actually use, and I'll give you the version without the hedge. Self-host when the workload is small, stable, and the data is the business. Buy SaaS when the workload is spiky, the compliance burden is somebody else's problem to carry, and the thing isn't core to what the client sells. That's it. Most of the arguments you'll hear are people rationalizing a decision they already made.

Let me get concrete, because "it depends" is how consultants bill hours and how founders lose trust.

The math that actually decides it

Take a mid-size client: 40 people, one internal tool, maybe 200 GB of data. SaaS at $25/seat/month is $12,000 a year and climbing every renewal. A $40/month VPS with 8 GB RAM and 160 GB SSD handles that workload until the heat death of the universe. Add backups — object storage at $6/TB/month, so call it $15 — and you're at roughly $700 a year. Two years of that is less than two months of the SaaS bill.

But the license cost is the small number. The real cost is you. If you're not already comfortable with systemd, nginx, postgres, and a firewall that isn't a joke, self-hosting is a second job you didn't quote for. I've seen a founder save $30k on licenses and burn $60k of engineering time relearning what a reverse proxy is. That's not a win. That's a story you tell at a conference.

The honest test: can one competent person on your team run journalctl -u yourapp -n 200 --no-pager at 2am and know what they're looking at? If yes, self-host more than you think. If no, fix that first. It's a two-week skill gap, not a personality trait.

Where SaaS genuinely wins

I'm not a zealot. There are places I'd never put a self-hosted box in front of a client.

Anything with a real compliance perimeter — SOC 2, HIPAA, PCI — where the vendor has already paid the auditors and you haven't. Anything that's genuinely bursty, like a queue that sits idle at 3 requests per second and spikes to 40,000 for two hours on a product launch. Anything where the vendor owns the hard part of the problem — payments, email deliverability, phone numbers. I will not fight Postfix for a client's transactional email. I'll pay the $20 and sleep.

The other honest case: when the client's own team can't operate the thing and won't learn. A self-hosted system nobody maintains is worse than a SaaS bill, because the failure mode is silent. The database fills the disk. The backup cron was never tested. You find out when the client calls and asks why the app is down and you're on a plane.

What owning the server actually buys you

Three things, and none of them are cost.

First, the data stays. When the vendor changes pricing, you don't migrate — you just keep running. When they get acquired and the roadmap dies, you don't panic. I've had clients on the same Postgres instance for six years while the "industry-leading" alternative changed hands twice and shut down a product line. That's not luck. That's not being on someone else's spreadsheet.

Second, you can actually debug. When a SaaS product misbehaves, you file a ticket and wait. When your own nginx returns 502s, you run tail -f /var/log/nginx/error.log, see the upstream timeout, bump proxy_read_timeout, done. The feedback loop is minutes instead of days. That's the whole game.

Third, the economics scale the way you want. Per-seat pricing punishes growth. Self-hosted infrastructure doesn't care if you go from 40 users to 400 — the server does the same work, and you add a $20/month box when it doesn't. I've watched a client's SaaS bill go from $800 to $9,000 a month over three years purely because they hired people. They self-hosted two of the four tools and cut that to $1,100.

The stack I actually reach for

Linux, always. Debian or Ubuntu LTS. Not because they're trendy — because the documentation is real and the failure modes are known.

Python for anything custom. FastAPI behind uvicorn with gunicorn as the process manager, or just uvicorn --workers 4 if you're feeling modern. Postgres, not MySQL, not SQLite for anything with more than one writer. pg_dump on a cron, shipped to object storage with rclone. Test the restore. I mean actually test it. Untested backups are a bedtime story.

For deployment: docker compose for anything with more than two services. Not Kubernetes. Kubernetes is a solution to a problem you don't have and a resume you're not writing. I've seen a three-person company spend four months on a cluster for a workload that fits on one box with room to spare.

Reverse proxy: caddy if you want TLS to just work with two lines of config, nginx if you want to know exactly what's happening. Both are fine. Pick one and stop reading comparison posts.

Monitoring: netdata on the box, plus a curl health check from outside that pings you when it fails. That's it. You don't need a $400/month observability platform for a single server. You need to know when it's down and why, and netdata tells you both for free.

Backups: 3-2-1. Three copies, two media, one offsite. restic to object storage covers the offsite leg and encrypts by default. restic snapshots and restic restore latest --target /tmp/test — run those monthly. If the restore takes longer than the RTO you promised the client, you have a problem and you found it at a good time.

The uncomfortable part

Self-hosting means you own the outage. Not the vendor. You. When the disk fills at 3am because logs weren't rotated, that's your phone. logrotate is not optional. Neither is unattended-upgrades for security patches, or a firewall that drops everything except 22, 80, and 443 — ufw default deny incoming and then explicitly allow what you need.

I've been the guy on the phone at 3am. I've also been the guy who watched a client's SaaS vendor go down for six hours on Black Friday and had nothing to do but forward the status page. Guess which one I'd rather be. Owning the server means you have a pager and a fix. Renting means you have a ticket number and a waiting room.

The clients who get burned by hype are the ones who bought the story that infrastructure is somebody else's job. It isn't. It never was. The SaaS vendor has their own infrastructure problems — you just can't see them until they hit you. Oracle is laying off people to pay for AI infrastructure and Microsoft is writing a code of conduct for its models — that's the same industry telling you it can be trusted with your data while it restructures its own cost base. I'm not saying don't buy anything. I'm saying know what you're renting and why.

What I'd actually do this week

Pick one tool the client pays per-seat for that stores data they'd hate to lose. Export it. Stand up a Debian box, install Postgres and Python, write the migration script, run both in parallel for two weeks. Cut over when the self-hosted version passes the same tests. Keep the SaaS around for a month as a fallback. Then cancel it and put the savings into backups and a second box.

If you want the shortcut, we build and run exactly this at hub.sqs.chat — self-hosted, Linux-first, no vendor lock, no per-seat nonsense. But you don't need us to start. You need a terminal and an afternoon.

Stop dithering. The server isn't going to install itself.

References

AI-assisted, curated for Side Quest Studios.