Should you host it yourself? The hidden cost of rolling your own

The "it's basically free" trap

A VPS is a few dollars a month. A cloud console account takes ten minutes to open. Next to a hosting quote, that sticker price looks like the obviously cheaper answer — so a lot of teams take it without pricing the other side of the ledger: the hours they'll spend keeping the thing alive, every week, for as long as it runs.

That's not a trick question with one right answer. Sometimes rolling your own is genuinely the right call. But it's worth pricing on purpose, not defaulting into because nobody wrote the other number down.

What you're actually signing up to run

None of this shows up on the console's pricing page, and none of it is optional once real people depend on the thing staying up:

TLS + DNS

Certificates renewed before they expire; records kept correct as the app changes.

Backups, with tested restores

A backup nobody has restored from is a hope, not a backup.

Monitoring & on-call

Uptime and error rate watched continuously — and someone who answers when it pages.

Patching

The operating system and runtime kept current against known vulnerabilities.

Incident response

Someone who diagnoses and fixes it at 2am, not just gets notified about it.

Scaling

Capacity adjusted as traffic changes, instead of found out about during an outage.

That's the same list what "managed" actually meanswalks through in full — this guide is about the decision to buy it at all, not what's in the box once you have.

Pricing the hours honestly

Don't reach for an industry-average figure — nobody's stack or team is the average. Instead, use a method and put your own numbers into it:

• Count the hours a normal month actually takes: patch windows, certificate checks, watching a dashboard, restore drills, the odd 2am page. Most teams underestimate this because it's spread thin across the week instead of arriving as one visible bill.
• Apply your own hourly rate to those hours — whatever that person would otherwise be doing, including product work that doesn't happen while they're patching a server.
• Add the incident tax: the outage that takes an entire evening, the restore that turns out not to work the one time it's needed, the patch applied late because everyone was busy. It's infrequent, but it isn't zero, and it's the part flat-rate hosting is priced to absorb.

Once that's a real number instead of "well, the server's cheap," it's a fair comparison against a hosting quote — not a sticker-price one. The hours ledger runs this method for you — put your own numbers in and it does the arithmetic.

When doing it yourself is the right call

Sometimes the honest answer is: keep doing it yourself.

• Hobby or learning projects, where the point is the tinkering, not the uptime.
• You're already staffing a platform engineer whose job includes exactly this list — the hours are already paid for.
• Hard data-residency or control constraints that mean the infrastructure has to be something your own team operates directly, full stop.

In any of those, self-hosting isn't a false economy — it's just the right shape for the job.

When to hand it over

The line is simple: when the app matters, when uptime matters to someone other than you, and when your time is worth more spent on the product than on the platform underneath it. That's the point where the hours priced above stop being a rounding error and start being the real cost of the "free" option.

You're not just buying ops — you're buying iteration

Self-hosting doesn't only mean owning the operational list above forever. It means owning every future change to the platform yourself too — the next migration, the next scaling decision, the next security patch that needs a maintenance window nobody has time to plan.

The loop works differently: CustomLabs builds the app, CodeHerder's agents iterate on it after launch — brief a change in plain language, an agent opens a pull request, and the change ships through the same pipeline already serving the site — and CustomHosted keeps the result running underneath. One handoff covers both the ops and the ongoing iteration, instead of the app being "done" the day it ships and drifting from there. The full write-up is on the loop page, andkeep shipping without a dev team covers how a change actually ships end to end. More on the build side atcustomlabs.io, and the pipeline itself isCodeHerder.