If you're building alone, the honest rule is this: pay for anything that pages you at 2am, and self-host anything whose failure just means you fix it tomorrow. A managed database, error tracking, and email deliverability are worth real money because their failure modes are expensive and silent. A background worker, a status page, or an analytics dashboard usually isn't — the open-source version costs you an afternoon, not a career. The trap isn't spending too much; it's spending on the wrong layer and self-hosting the one thing that will quietly lose your data.
This is a build-vs-buy post written from the seat of someone who is the entire on-call rotation. The math changes when there's nobody to hand the pager to.
How do you decide pay-vs-self-host when you're the only engineer?
The usual framing — "compare the monthly bill to the alternative" — is wrong for a solo dev, because the alternative isn't free. It costs your hours, and your hours are the one input you can't buy more of. The number that actually matters is cost of failure × probability you're asleep when it fails.
Run every component of your stack through three questions:
- What happens when it breaks at 3am? If the answer is "data loss" or "customers can't pay," that's a paid, managed layer. If it's "a chart is stale until morning," self-host it.
- How often will I touch it? Something you configure once and forget (a status page) is a weak case for a subscription. Something that needs patching, scaling, and monitoring (a Postgres primary) is a strong one.
-
Is the managed premium buying me a real SLA or just a nicer UI? Sometimes you're paying $20/month to avoid
docker compose up. That's a bad trade. Sometimes you're paying for someone else to be woken up instead of you. That's the best trade there is.
The takeaway: don't optimize the invoice, optimize where the pager points. A solo developer's cheapest month is the one with no incidents, not the one with no subscriptions.
What's actually worth paying for in 2026?
Here's how I'd split a typical solo SaaS stack. Prices move constantly, so I'm describing pricing models and tiers as of mid-2026 rather than quoting exact figures — check current pricing yourself before you commit.
| Layer | Default: pay or self-host | Why |
|---|---|---|
| Primary database | Pay (managed) | Backups, failover, and point-in-time recovery are not things you want to test in production |
| Error tracking | Pay (with a self-host escape hatch) | You need to know about the crash before your users tell you |
| Transactional email | Pay | Deliverability is a reputation game you cannot win from a self-hosted box |
| Auth | Pay initially | Rolling your own session/password reset flow is where subtle security bugs live |
| Background jobs / queue | Self-host | A Redis-backed worker on your existing box is boring and reliable |
| Object storage | Pay (commodity) | Cheap, solved, and S3-compatible APIs are everywhere |
| Analytics | Self-host | Failure is invisible to users; the OSS options are excellent |
| Status page | Self-host or free tier | Configure once, rarely touch |
| Uptime monitoring | Pay (cheap tier) | It must run off your infra to be useful |
The two I'd never cheap out on: the database and email. A managed Postgres — the kind DigitalOcean, Supabase, Neon, or your cloud provider offers — is the one line item where the managed premium directly buys you automated backups and a restore button you'll pray for exactly once. If you want a managed Postgres that scales to zero for a hobby project and still gives you branching for safe migrations, Neon is the one that handles cold-start and preview databases without you running a server. For email, the deliverability problem is unsolvable at solo scale on your own IP — a warmed sending reputation takes months and one spam complaint to lose. When you just need transactional email that lands in the inbox without you babysitting DKIM and IP warmup, Resend is the option built around that developer workflow.
The takeaway: pay for the layers where the failure is either invisible until it's catastrophic (backups) or unrecoverable by effort (email reputation).
What's cheaper to self-host once you count the real cost?
Self-hosting has a hidden bill: patching, monitoring, and the 2am page. For most solo devs that bill is only worth paying on components that are stable, low-touch, and low-blast-radius. Three good candidates:
- Analytics. Privacy-friendly analytics you host yourself covers the "how many people visited" question completely. If you want product analytics without shipping your users' data to a third party, a self-hosted Plausible or Umami instance answers the traffic questions without the per-event pricing that scales against you. Downside, stated honestly: you now own the uptime of your own analytics, and you'll occasionally lose a day of data to a botched upgrade. For analytics, that's fine.
-
Background jobs. You almost certainly already run Redis or Postgres. A worker process reading a queue off it (BullMQ on Node, Celery/RQ or
pg-based queues on Python) is a hundred lines and no new vendor. The drawback is that you own retry logic and dead-letter handling yourself — but you should understand those anyway. -
Cron / scheduled tasks. A single small VM with
systemdtimers is more debuggable than most managed schedulers, and it never surprises you with a cold start.
Here's the honest counterweight: self-hosting is cheap until you have more than one server. The moment you're running three VMs by hand, you've quietly rebuilt a worse version of a platform, and the "free" stack now costs you a weekend a month. That's the signal to move that layer back onto a platform.
The takeaway: self-host the boring, stable, single-box components — and treat "I now manage more than one server by hand" as the alarm that you've overshot.
Where do PaaS platforms fit for a solo dev?
The middle ground — Render, Railway, Fly.io, and friends — is where a lot of the pay-vs-self-host tension actually resolves. A platform-as-a-service lets you not run servers while not wiring up a cloud provider's full IAM-and-VPC ceremony. For a solo developer, that's frequently the right altitude: you get managed deploys, TLS, and a database add-on without becoming a part-time SRE.
The trade-off is real and worth naming: usage-based platform pricing is comfortable at hobby scale and can get sharp as you grow, and you're accepting some lock-in around their build and networking model. If you want to deploy a containerized app close to your users without managing Kubernetes, Fly.io is the one built around running full VMs at the edge — with the caveat that you're now responsible for understanding its volume and networking model.
The takeaway: a PaaS is the default "buy" for compute when you're solo — right up until your bill or your scaling needs make a plain VM cheaper and more predictable.
FAQ
Is it cheaper to self-host Postgres than to use a managed database?
On the raw compute line, yes — a Postgres container on a small VM costs a fraction of managed Postgres. But that ignores backups, failover, upgrades, and the hours you'll spend on them. For a solo developer, managed Postgres is almost always cheaper once you price your own time and the cost of a bad restore. Self-host it only if the data is genuinely non-critical.
What should a solo developer never self-host?
Transactional email and your primary database backups. Email deliverability depends on a sending reputation you can't build alone, and database recovery is something you want to be someone else's fully-tested job, not your untested script. Auth is a close third — roll it yourself only if you enjoy debugging session-fixation bugs.
When does a managed service stop being worth it?
When you're paying mostly for a nicer UI rather than an SLA, and when usage-based pricing starts scaling faster than your revenue. Analytics and background jobs are the usual first candidates to bring in-house, because their failures don't wake you and the open-source versions are mature.
Bottom line
If you're solo, buy the layers where failure is catastrophic or unrecoverable by effort — managed Postgres, transactional email, error tracking, and auth — and self-host the boring, low-blast-radius ones like analytics, background jobs, and cron. Reach for a PaaS as the default for compute until scale makes a plain VM cheaper. The one metric to optimize is not your monthly invoice; it's how many of your components can fail without waking you up. Spend money to move the pager off your nightstand, and self-host everything that can wait until morning.
