The Hosting Trap: Why I'm Done Building Platforms That Host Other Software
I love hosting. I genuinely do.
There’s something satisfying about taking a piece of infrastructure, wrapping it in a clean interface, and letting someone else get value from it without touching a terminal. I’ve done it three times now — ClawHosting.io, MicroDB.io, and gserver.io. AI agents, managed databases, Minecraft servers. Three different products, three different target audiences. But the same underlying model: you spin it up, they use it, you manage it.
And I’ve learned something the hard way: the build is the easy part.
───
I Know How to Build These Things
Let me give credit where it’s due. I’m good at this.
I can spin up VMs (lots of them) cheaply and efficiently. I know how to containerise a workload, automate provisioning, build a billing layer, and get a customer from sign-up to a running instance in under two minutes. I have a deep infrastructure background — Kubernetes, cloud-native architecture, IaC — and I know how to keep costs low while keeping the stack clean.
The initial build of a hosting SaaS feels great. You’re solving real problems. Customers sign up. They’re happy. You ship features. It works. You feel like a founder.
Then six months pass.
───
The Maintenance Wall
Here’s what nobody tells you when you’re building a managed hosting product: every customer is a unique production environment, and you are personally responsible for all of them.
Minecraft released a new version? Every customer’s server needs to be evaluated, tested, and migrated. Some of them have custom mods. Some of those fail, go out of memory. Some of them have configuration quirks that break on the new version. Each one is a conversation.
OpenClaw pushed an update? Same story. Some customers are on the old version intentionally. Some have customised their setup in ways that don’t survive an upgrade. You either let them lag behind (which creates fragmentation) or you upgrade them (which creates incidents).
A database customer wants a specific PostgreSQL extension enabled? That’s not a one-click config change — that’s a support ticket, a manual intervention, a test, a restart, a hope-nothing-breaks moment at 11pm.
Multiply that by your number of customers. Now you start to feel it.
───
Late Nights Add Up
I’m not talking about the occasional late night. I’m talking about the persistent hum of production responsibility.
A customer’s Minecraft server goes down at 2am on a Saturday — their friends are waiting to play. That’s my problem. A MicroDB connection string stops resolving because of a network hiccup on the VM? That’s my problem too. A ClawHosting customer’s agent stops responding after an upstream update? You guessed it.
These aren’t big failures. They’re small fires. But small fires at scale, across three products, with no team — that’s a burn.
I got into this because I wanted to build products. Somewhere along the way I became a part-time sysadmin, part-time support engineer, and part-time release manager for other people’s software.
───
The Pattern I Missed
The thing I didn’t account for is the difference between hosting infrastructure and hosting software.
If I rent you a VM, I’m responsible for the hardware layer. That’s clean. That’s well-understood. Cloud providers have been doing that for twenty years.
But if I host Minecraft for you, or OpenClaw, or MySQL — I’m now responsible for the application layer too. Every bug in that software, every version bump, every edge case in their configuration model — it lands in my support queue. I don’t control the software. I don’t write the software. But I own the customer experience of it.
That’s a fundamentally different business. And it’s one I underestimated.
It can be done but definitely not by one person. Needs a team, a big team. I have to scale.
───
What I’m Doing Differently Now
I’m not building another hosting-like SaaS. Not because it’s a bad business — it can be a great one. But it requires a team, processes, and an appetite for production maintenance that I’m not willing to invest in solo.
From now on, if I build a product, it has to follow a rule: I own the full stack. The logic, the bugs, the upgrades. No more wrapping third-party software and hoping the upstream team doesn’t break my customers in the next release.
My next one is ottero.com.au. It is a product that I own end to end. I control everything. It is not a hosting product. It is a product that I built from scratch.
The products I want to build are ones where a version bump is something I ship, not something I survive.
───
The Lesson
Three hosting platforms. Real customers. Real infrastructure. Real value delivered.
And a very real lesson: the moat in hosting isn’t the tech — it’s the operations. If you can’t invest seriously in ops, monitoring, support tooling, and a release management process, the product will slowly consume you.
I built it. I ran it. I felt the weight of it. And now I know exactly what kind of builder I want to be.
Stop configuring. Start building from scratch!