Services / Kubernetes platform
Build it, or take it over
Kubernetes platform engineering & Day-2 operations
Platforms drift. Upgrades get postponed, the person who built it moves on, and reliability slides. We take the whole system on and keep it current: on-premises, hybrid, or in your own cloud.
Greenfield buildout, or a platform that won’t stay reliable. Paid, fixed scope, typically one to two weeks. Not ready for that? Send us the shape of your platform and get a written reply within two business days.
Build it
A platform is more than a cluster. We design and build the control plane, distributed storage, networking, and the security model together, so the result is something your team can actually operate.
We work deepest on bare metal and in a private cloud, where the whole stack is yours to shape. On a managed cluster you already run, whether that’s EKS, GKE or AKS, the provider keeps the control plane and we start at their boundary. When the buildout is a full private cloud, the productized path is SECO, our sovereign private cloud.
Run it
The real work of a platform starts on Day-2. We bring the SRE discipline that keeps it reliable: SLOs, on-call and blameless incident process, observability, capacity planning, and the automation that removes toil. We stand behind what we run, under SLA.
Most of what makes a platform expensive on Day-2 is staying current. We own version currency and upgrade sequencing across the cluster, its storage and networking layers, the review of APIs removed in the target version ahead of each upgrade, and the add-ons and operators that quietly fall behind. Where the control plane is yours rather than a provider’s, that also covers certificate lifecycle, etcd health and a restore you have actually tested. Cadence and thresholds are set per engagement and written into the SOW.
A platform the organization runs on
We stand up a self-service Internal Developer Platform, built for the people who operate it as much as the people shipping on it. Golden paths make the right way the easy way.
- Control plane, distributed storage, networking, and security, designed as one system
- Self-service IDP and GitOps delivery your teams operate themselves
- Observability, SLOs, on-call, and blameless incident process
- Run it to a defined SLA, or transfer it to your team with the runbooks to own it
Three ways in
We run it. We operate the platform to the agreed targets on a retainer.
Your team runs it, we take the escalations. Your engineers own the day to day and open a ticket when something is beyond them: an upgrade that will not land, a failure they have not seen before, a design decision they would rather not make alone. It runs through tickets rather than a phone line, which keeps the answer written down and searchable the next time it happens.
Fixed-scope project. We stabilize the platform and hand it back.
All three start with a Kubernetes platform assessment, and pricing is set per engagement, against the scope. If you go ahead with the engagement, the assessment fee credits against it.
Who ends up running it
Build it, run it, and hand it over when you are ready. We operate the platform to the agreed targets for as long as that is useful to you, and transfer it to your team on your request rather than on a date we set. Where handover is the plan, we can work through it with your engineers or point you at the vendor training that fits.
What transfers can include the automation itself: the playbooks, the manifests and the runbooks, assigned to you in the SOW. There is no contractual lock-in either way: leave a retainer on notice.
What we do not do
We do not build your applications, and we do not own the pipelines that build, test and ship them: that toolchain stays with your teams, whichever one they run. What we keep in git and reconcile is the platform’s own state. We do not build or operate your AI: the models, agents, gateways and MCP servers are yours unless we agree otherwise in scope. We run the platform underneath all of it, and we are better at that because it is the only thing we do.
The other two options
You can hire for this, or buy a managed service. Both are real answers and we will tell you when one of them fits better than we do.
Hiring. An engineer you hire owns the platform and sits inside your organization, which is the closest thing to full control. The catch is the sentence at the top of this page: the person who built it moves on. A platform owned by one employee is one resignation away from where you are today, and the hire itself takes months while the upgrade debt compounds.
A managed service. Most providers run the platform on their control plane, their tooling and their opinions; a few instead run open-source components inside your own environment. If what you want is one vendor accountable for everything, that is the cleaner purchase and you should make it. What it costs you is ownership: the platform is theirs, so leaving later is a migration rather than a handover. What we build runs on upstream components and stays yours throughout.
Where we sit. Between the two. You get an operator’s depth without carrying the headcount, on a platform you could take back at any point, including from us.
Why this practice
The work is led by a principal engineer with more than seventeen years in infrastructure, most of it running platforms for other people’s production rather than one in-house estate. At a regional cloud provider and managed-service provider that meant a fleet of dedicated Kubernetes clusters, some internal and some on clients’ own premises in regulated sectors, along with the upgrade cadence, the on-call rotation and the post-incident reviews that come with owning them. That is operating experience, not a diagram. The certifications sit behind it, including the full CNCF Kubestronaut set, which only a few thousand engineers worldwide hold.
We already have a platform, built by someone else. Will you work with it or rebuild it?
Work with it, in almost every case. The assessment establishes what you are running, which parts are load-bearing, and where it has drifted. A rebuild is a recommendation we make only when repair honestly costs more.
How is this different from SECO?
This engagement builds and runs a Kubernetes platform on what you already have, or on what you choose. SECO is our own productized sovereign private cloud, delivered as one platform in stacking packages. When the buildout is a full private cloud, SECO is usually the shorter path.
What does “under SLA” actually cover?
Availability and response targets defined per engagement and written into the SOW, documented runbooks, on-call coverage as agreed, and post-incident reviews on a defined cadence. Response is sized per engagement and set against how the platform actually runs.
Do you replace our team, or work alongside it?
Alongside it. The engagement is principal-led, with senior specialists brought in as the work requires, and it is designed to leave your team able to run what we build.
What access do you need?
We work within your access controls and change process, with least-privilege credentials and an auditable trail, so your security team sets the boundaries and we operate inside them. Onboarding starts with access and an inventory before anything touches production.
Standing up or stabilizing a platform?
Tell us where the platform is today and what is forcing the decision. A written reply within two business days: our read on your situation, or the questions we need answered before we can give you one.