Building a managed hosting business as a team of one

A managed hosting business is a promise to be there when things break. Now do that as one person, with a finite number of hours and a need to sleep. That tension is the whole story of building Stackbastion solo, and this is an honest look at how I’m thinking about it.

I run this alone right now. Not “small team,” one person. That shapes every decision, and pretending otherwise would set the wrong expectation with the exact people who most need to trust me.

The core problem with solo managed hosting

Most solo businesses sell something you deliver and walk away from. A course, a template, a design. Managed hosting is the opposite. You’re selling ongoing responsibility. The product is “I’ll keep watching this for you,” and watching never stops.

That runs straight into a hard limit: one person is not on call 24 hours a day, seven days a week, forever. Anyone who tells you they are is either lying or about to burn out and drop your app. So the honest question isn’t “how do I be everywhere at once.” It’s “how do I build something that mostly doesn’t need me, and be genuinely good the few times it does.”

Everything below follows from that.

Where the time actually goes

Building this, my hours split into rough buckets. The proportions aren’t fixed, but the shape is real.

• Product and infrastructure. The actual system that runs customer apps: the Hetzner setup, Docker, Caddy, Postgres, backups, monitoring. This is where reliability is bought or lost.
• Automation. Turning things I do by hand into things the system does by itself. Every hour here buys back many hours later. For a solo operator this isn’t a nice-to-have, it’s survival.
• Content and marketing. The site, these posts, explaining the thing so the right people find it. Slow to pay off, but the only way a solo business gets discovered without a sales team.
• The boring company stuff. Legal, invoicing, the GDPR paperwork, decisions that have to be made and can’t be delegated to anyone.

The trap is obvious once you see it. Support and firefighting can eat all four buckets if you let them. One person spending every day reacting has no time to build the automation that would stop the fires. So the discipline is protecting the automation time even when something is smoldering.

What one person can honestly promise

This is where a lot of solo founders oversell and get caught. I’d rather draw the line clearly.

What I can promise: monitoring that watches your app so I don’t have to stare at it, backups that are tested so a restore actually works, and a named human, me, who responds within a stated window when something breaks. Not “instant,” a real, honest window.

What I can’t promise as one person: a literal one-minute response at 4am every night of the year. That’s a team’s promise, not an individual’s. If I claimed it, the first time I was asleep or on a train I’d break trust with the exact customer who needed it most.

The way you square that circle is to make the system resilient enough that most incidents don’t need a human at all. Good backups, a database that won’t fall over under load, restart policies that self-heal, alerts that catch problems early. The goal is that when the phone does ring, it’s rare and it’s real.

Automate, or don’t offer it

The rule I keep coming back to: if a task doesn’t scale to one person handling many customers, either automate it or don’t sell it.

Onboarding, backups, monitoring, patching, restart-on-crash, the routine health checks. All of that has to run without me typing commands, or it caps how many customers I can serve at a number too low to matter. A solo managed-hosting business that requires manual work per customer per day isn’t a business, it’s a job with extra steps.

Where I deliberately keep the human is the small set of things that genuinely need judgment. A weird incident. A restore where you need someone calm on the line. A migration that could go wrong. That’s where a named human beats a support bot, and it’s exactly where I want to spend the human hours I have. Everything else gets automated until it’s boring. There’s more on that tested-restore discipline in why untested backups fail when you need them.

The honest risks of buying from a solo operator

If you’re considering handing your app to a one-person company, you should weigh the real downsides. I’d rather say them than have you discover them.

Bus factor. It’s one person. If I’m sick, on a plane, or genuinely offline, the human-response part slows down. I mitigate this with automation that keeps your app running without me and with tested backups so your data is safe regardless, but the honest version is: a team has more redundancy than I do.

Capacity. I can only take on customers as fast as I can serve them well. Growth is deliberately slow. That’s a feature for the people I do serve and a limit on how many that is.

Longevity. Fair to ask what happens to your app if the business stops. The answer baked into the design: your app runs in Docker with standard Postgres, no proprietary lock-in, so you can always take it and leave. That portability is on purpose, precisely because I’m one person.

I don’t think these outweigh the upside for the customer who currently has no backups, no monitoring, and no one to call. But you should decide that with the real trade-off in front of you, not a glossy version.

Why solo, then

Because the alternative to a careful solo operation, for this customer, is usually nothing. The person with an outgrown AI app and no ops knowledge isn’t choosing between me and a 20-person managed-hosting firm. They’re choosing between me and hoping their app doesn’t break. I’ll take that comparison.

Solo also keeps me honest. Every promise on the site is one I personally have to keep, so I write them carefully. There’s no sales team writing checks the ops team has to cash. It’s the same person.

If you want to know who that person is and why any of this exists, it’s on the about page. If you’d rather just find out where your app stands, the free audit does that without any commitment.

FAQ

What happens if you’re asleep when my app goes down?

The system is built so most incidents don’t need me awake to survive: self-healing restarts, monitoring, and tested backups keep your app and data safe. For incidents that do need a human, I respond within a stated window rather than pretending I’m awake 24/7. Honesty about that window is the point.

How many customers can one person actually handle?

More than you’d guess, because the routine work is automated, but a real and finite number. I grow deliberately so every customer stays well served. If I ever can’t take you on well, I’ll say so rather than take your money and stretch too thin.

What if the business shuts down? Do I lose my app?

No. Your app runs in Docker with standard Postgres and no proprietary lock-in, so you can always export it and move to another host or in-house. That portability is deliberate, precisely because I’m one person and you deserve an exit.

Isn’t a bigger company safer for hosting?

A bigger team has more redundancy, true. But bigger also often means slower, less personal, and a support queue instead of a named human. For a small outgrown app, tested backups and someone who actually knows your setup usually beat a large company where you’re ticket number 4,812.