They stopped calling us when things break.
Clients stopped calling us when things break, and started calling us to build what is next. Release engineering, staging environments, secure access and migrations run as projects now fill the engineering queue.
In this article 3 sections
- Clients stopped calling us when things break, and started calling us to build what is next.
- What fills the engineering queue now: release engineering, staging environments, secure access, migrations run as projects. The work you hire an engineering team for.
- Most incidents on our desk are opened by us, not by the customer: monitoring reaches in first.
- The builds land because the layer underneath is ours: the metal, the SAN, the network on our own AS, and the engineers who run it.
The shape of our support desk has changed. The queue that keeps growing is the managed-engineering one: release engineering, staging environments, secure access, migrations run as projects. The proof of what we have become is not a testimonial. It is the work our clients bring us, and what they ask us to be.
Break-fix did not go away. It stopped being what clients call about most. A host that answers at 3 a.m. earns the right to be asked about what happens at 9 a.m. on launch day, and that is the conversation the engineering queue is made of.
What they hire us to build now
What fills the engineering queue now, most common first:
- 01CI/CD and live-release work: sitting through deploys and go-lives
- 02Staging and pre-production environments
- 03Secure access: site-to-site, per-customer gateways, remote-staff rollouts
- 04Security hardening
- 05Performance engineering
- 06Migrations run as projects, and the architecture behind them
Migrations, architecture, and automation look small in the ticket data for a reason: the biggest builds graduate out of the ticket system entirely and run as projects, with a survey, a green-light, and a cutover playbook. The most valuable engagements were never tickets at all.
The proof of that lives below the waterline, in the builds that stopped being tickets: a self-service control center we built into a customer's own portal (every VPN change runs through our ticket queue), a publisher's platform re-architected and landed on our metal (a migration is a project, not a ticket), and an agency's whole staff onto secure access in one afternoon. None of them fit in a ticket.
Most incidents, we open first
One more thing, because it belongs to the same shift. Most incidents on our desk are opened by us: monitoring reaches in before the customer notices. A break-fix desk waits for you to notice. Read more on how our support desk operates.
Why buy this from a host at all
Against hiring in-house: a senior infrastructure engineer, plus a SAN, plus an on-call rotation is a serious commitment and a hiring cycle before anyone writes a line. We are the team and the datacenter, available now.
Against a freelancer or an agency: they build on infrastructure someone else runs. When it breaks at 3 a.m., they file a ticket with a host they do not control. We build on infrastructure we also operate, so the person who architected it is the person who fixes it.
Against hyperscaler support: a support tier and a queue, on a bill that moves. Here it is one named human, end to end, no tiers, on fixed-cost hardware we own. The difference is not a feature. It is who picks up.
Rented, and tiered
Someone else's metal, answered by a queue.
Owned, but tiered
They own the metal. You still get a support tier and a queue.
Named, but renting
A real person who builds on infrastructure they don't run.
Owned, and named
The engineers who run the metal are the ones who answer.
The builds land because the layer underneath is ours: the metal, the SAN, the network on our own AS and BGP, the firmware engineers on staff. The relationship is the product. The owned platform is why it works, and why nobody renting theirs can copy it. Break-fix is not the past we are leaving. It is what we got good enough at that clients started asking us for more.
“Clients stopped calling us when things break, and started calling us to build what's next.”
Straight answers
What does fully managed hosting actually include?+
The layer under the application is ours: provisioning, migration, secure access, staging, observability, backup and DR posture, performance and security engineering, delivered by named engineers and increasingly as build projects, not just incident response. It is the work you would otherwise hire an infrastructure team to do.
What is the difference between break-fix support and managed engineering?+
Break-fix waits for a symptom and closes a ticket. Managed engineering designs, builds, and sits through the launch. On our own desk, the engineering queue has grown several times over since 2021 while the desk as a whole has not.
Can a hosting provider really do DevOps and CI/CD work?+
The largest demand in our engineering queue is exactly that: release engineering, deploy support, staging environments.
Isn't it cheaper to hire a freelancer for infrastructure work?+
The freelancer builds on infrastructure someone else runs, so the build and the 3 a.m. accountability split between two parties. Here they are the same team, on infrastructure that team also operates.
Bring us what's next, not just what broke.
A named engineer, end to end, on infrastructure we own. If it should be a project instead of a ticket, we'll say so.
Talk to an engineerYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer