Small and medium businesses want what large companies take for granted: a website and email that just work, backups they never have to think about, and someone to call when something breaks. What they don’t want is enterprise pricing or an ops team of their own.
That gap is why I started a hosting company and ran it for a decade.
Why clustered, and why AWS
Most budget hosting at the time was one big server per batch of customers. That’s cheap, but when the server has a bad day, so do hundreds of businesses. The platform was built on AWS as a cluster from the start:
- Separate roles for separate jobs. Web, DNS and backup duties were split across instances, so one failure didn’t take down everything.
- Clustered DNS, so domains kept resolving even if a single DNS node went down.
- Elastic infrastructure, so capacity could be added as customers arrived, without a hardware purchase and a data center visit.
Using cPanel/WHM as the management layer meant customers got a control panel they already knew, while the infrastructure underneath was far more resilient than they’d usually get at that price.
Automating so a small team could run it
A hosting company lives or dies by how much of its operations happen without a human. The aim was that a new customer could sign up and be live without anyone touching a server:
- Automated provisioning. Account, DNS zone, mailboxes and SSL were created from the order itself.
- Scheduled off-server backups for every account, so a failed server never meant lost data.
- Monitoring with automated recovery, where common failures like a stopped service were restarted automatically and an alert only went to a human when automation couldn’t fix it.
Running the business
Building the platform was the easy part. Running the company taught me the rest: setting budgets and sticking to them, pricing a service so it’s both competitive and sustainable, hiring and leading a team, and supporting customers who care about outcomes and not architecture.
That director’s view of the whole picture, from technology and money to people and customers, has shaped how I’ve approached every engineering role since.
What I’d tell another founder
- Design for failure from day one. Customers forgive a lot, but not lost data.
- Automate the onboarding path first. It’s where every new customer forms their first impression.
- Let automation handle the routine failures and save human attention for the unusual ones.
- Know your numbers. A technically great platform still has to make sense as a business.