Building the platform and the team that runs 700,000 websites

The situation

Large shared-hosting platforms have a particular failure mode: they grow by adding servers and people at the same rate, until a few hundred engineers are each hand-tending their own corner of the fleet. Provisioning takes a ticket. Migrations take a weekend. Every server is slightly different because every server was built by a different person on a different day. It works right up until it doesn't, and when it doesn't, nobody can say why.

At the first company I inherited exactly that: an operations organisation of more than a hundred people, a fleet measured in the thousands of servers, and a growing gap between what customers were promised and what the tooling could reliably deliver.

What I did

I treated the fleet as one system instead of thousands of servers. That meant writing the automation the platform had never had: a provisioning pipeline that built every server the same way, migration tooling that could move accounts between servers without a human copying files, and the telemetry to know which servers were actually busy rather than which ones people complained about. Where a task was done by hand more than twice, it became code.

Just as important was the operating model around it. I restructured the operations teams around the platform rather than around the ticket queue, put change control and incident review in place so the same outage could not happen twice, and wrote the runbooks that turned tribal knowledge into something a new hire could follow on their first week.

At the second company the brief was different: there was no platform function at all. I built the Platform Engineering team from scratch, hired the engineers, defined the standards for how infrastructure would be built and maintained, and delivered the first generation of fleet-wide automation so that the support and operations teams had a platform to stand on rather than a pile of servers to defend.

What it changed

Provisioning went from a ticket and a wait to a button and a minute. Migrations that had tied up a team for a weekend became a scheduled job. The operations organisation handled continued customer growth without growing headcount at the same rate, and the time engineers spent on repetitive work was redirected to the problems that actually needed a person.

The habits from that work are the ones behind DrivenHost and RelayPoint today: documentation as a deliverable, automation before headcount, and a refusal to run anything that cannot be rebuilt from a script.

← All work