Things exist because somebody made them once, in a console
Some cloud, usually more than one account. No landing zones, no blueprints, no security policy expressed anywhere except in people's habits, and little or no infrastructure as code. Nobody is certain what would happen if any of it disappeared.
- A production change went wrong and nobody could say what the previous state was.
- An audit asked for evidence of controls, and the evidence did not exist in written form.
- The cloud was built quickly by people who have since left.
- Resources exist that nobody is willing to touch, because nobody knows what depends on them.
Managed Cloud runs the cloud. This makes everything that happens to it reproducible.
Managed Cloud
The cloud itself — consulting, design, choosing the right services, implementing a workload and running it day to day. Terraform architecture and implementation, including greenfield.
Go to the pageKubernetes engineering
The cluster itself — designed, built, migrated, upgraded and secured. Project work, or run day to day under OpsHero Managed, on a cloud provider such as EKS or on VMs from Proxmox.
Go to the pagePlatform Engineering
The layer on top. It automates the entire lifecycle of the cloud after it exists: a GitOps strategy and its implementation.
A map of what exists, and a plan with a budget
You pay for the discovery only if you proceed.
A map of the estate
What actually exists across your accounts, rather than what the diagrams say.
A plan with a man-hour budget
Named outcomes, and the problems each one solves.
The efficiency position
What changes for the team and for the organisation.
The reliability position
Where the estate stands, and what the plan does about it.
From hand-made to declared
The example to hold onto: a MongoDB somebody created by hand becomes a declared GitOps resource — reviewed, reproducible, and recoverable.
Account structure and guardrails, expressed as code rather than as habit.
The operating model. Changes are proposed, reviewed and applied through Git.
Terraform underneath as the infrastructure layer, not as the headline.
A previous state that can be named and returned to, rather than reconstructed.
We become the platform team
A platform is not a project, it is a function. The choice is who staffs it. We stay on as the team that runs it — and the platform is built to be handed over even though we expect to stay.
What hiring a platform team actually costs
These are third-party figures, not OpsHero research. They are presented with their sources so you can check them and draw your own conclusion.
All-in annual cost of an in-house platform function at 30 to 80 engineers. Rising to $1.2–2.4M at 80 to 200. Salary and overhead is 70 to 85% of it.
Source: Platform Engineering Cost
Typical payback. The first six months are pure cost while the team is hired and ramped.
Source: Platform Engineering Cost
Of platform efforts fail to deliver impact. Close to half of platform teams are disbanded or restructured within 18 months.
Source: The New Stack
The honest case for buying rather than building is not that your engineers could not do it. It is that the hiring market, the ramp and the failure rate make it an expensive bet, and we have already absorbed all three.
A managed service provider
Will keep it running. Will not turn it into code, and has no commercial reason to.
A tooling vendor
Sells the container, not the content — and the content is the work.
Do nothing
Common, and it has a real cost: every manual resource is a future incident with no rollback.
OpsHero
Twenty years of running production, so the defaults come from operating systems rather than from designing them.
Your repositories. Your accounts.
All of it. For smaller clients that is already the model: we own the building blocks, your team uses the tooling. If you decide to take the platform in-house, it was built to be handed over.
The questions we get asked
We will be locked in.
Your repositories, your accounts, all of it. The platform is built to be handed over even though we expect to stay.
This sounds like it never ends.
It does not, and that is the design rather than an accident. A platform is not a project, it is a function — the choice is who staffs it.
We tried this before and it stalled.
Very likely true, given the failure rates above. What stalls is usually an internal team pulled onto other work, or a platform built for imagined needs rather than real ones. The discovery-then-plan sequence attacks the second; being an outside team with a contract attacks the first.
Our infrastructure is too messy to codify.
That is the actual starting state for most of this work. The mess is the engagement, not a disqualification.
Why not just get Managed Cloud?
Because Managed Cloud runs what exists. It does not make what exists reproducible.
Can our own team learn this?
Yes, and for smaller clients that is the model already: we own the building blocks, their team uses the tooling.
Roughly 30 engineers is the threshold
Published cost modelling puts the threshold for a dedicated platform function at around 30 engineers, with almost nobody under 20 needing one, and organisations above 80 paying more by not having one. Below that range, SDLC Golden Paths is the better fit — we will say so on the call. Source: Platform Engineering Cost
Book the discovery
You get a map of what actually exists in your estate, and a plan you can act on — and you pay for it only if you proceed.
- A map of what actually exists across your accounts
- A plan carrying a man-hour budget and named outcomes
- The problems it solves, and the efficiency gains for team and organisation
- The reliability position