Platform Engineering Consulting
a slide deck about platform strategy — We build the platform with your team and hand it over ready to run.
Consulting and delivery for teams whose releases wait on their own platform: internal developer platform, CI/CD and Kubernetes operations. We build it with you and hand it over, rather than recommending it.
We work in your repository, in your cluster, through your reviews. The engagement ends when your team changes the platform without us — not when a document is signed off.
Get in touchWhy platform work stalls
Platform work rarely fails on the technology. It fails because nobody ever finishes it: the team keeps operations running, and the platform stays the project for later.
What is left is a half-built layer in between. Scripts one person understands. Pipelines that look different in every team. A cluster nobody wants to be the one to change.
Every week in that state costs delivery speed, and it costs it in every team at once, because they all take the same route into production.
What is different afterwards
Not a vision, but states that are either true at the end or are not. Each of them can be checked together with your team.
- A team ships a new service to production without opening a ticket with the platform team.
- Infrastructure is described declaratively and rolled out through the same path as application code.
- A cluster upgrade is a planned piece of work with a runbook, not a risk that moves to the next quarter.
- New developers reach their first own deployment through a documented environment.
- Your team changes the platform itself — including the parts we built.
Which of these are reachable depends on where you start. We say which ones we consider out of reach before the proposal, rather than writing them into it.
What is included
The path from commit to production
We walk the delivery path ourselves and write down which stage takes how long, where it waits, and who has to step in.
Internal developer platform
Self-service for the routes teams take daily: new service, new environment, new deployment. Built as an interface your team can extend.
CI/CD and GitOps
Pipelines that build reproducibly, and a declarative rollout path that produces the same state in every environment.
Kubernetes operations
Cluster build and operational readiness: upgrade path, resource limits, access rights, and runbooks for the things that surface at night.
Observability
Metrics, logs and traces in one place, wired to exactly the alerts somebody actually responds to.
Handover
Documentation, pair programming, and a session where your team changes the platform without us. The engagement ends after it.
Implementation and knowledge transfer
We agree the scope before implementation starts. Booking a separate assessment is not a prerequisite.
Agree the scope
Clarify goals, the technical context and responsibilities together.
Analysis
We read the repositories, pipelines and clusters ourselves and write down which bottleneck has which effect on delivery speed.
Delivery inside the team
Every change goes through a pull request somebody on your team reads. We work in your repositories, not alongside them.
Handover
Joint operational handover, documentation, and a list of the things we deliberately did not build — with the reasoning.
Technical resources
What is not included
The scope of an engagement is only clear once its other half is written down too. These four requests are the ones we turn down in platform work — better before the proposal than halfway through the project.
Round-the-clock operations, on-call cover and SLA-backed run responsibility
We build platforms and hand them over ready to run. Running them is a different business — a managed-service provider can commit to that, we cannot.
Certificates, audit sign-off and conformity statements
Engineering work towards ISO 27001, NIS2 or the EU AI Act is in scope. Issuing the attestation is not: that takes an accredited auditor, not an engineer.
Projects with no in-house engineering team
Knowledge transfer is part of every engagement. With no team to hand over to it turns into permanent outsourcing — a model we do not offer.
A fixed price for a whole transformation, quoted before anyone has looked
Pricing an unexamined legacy estate is guesswork. We estimate after a short assessment — and we will say so when the rebuild is not worth it.
Questions we get about platform work
Do we need a platform team for this?
Not a platform team, but an engineering team. We hand the platform over to people who will change it afterwards; without them the engagement becomes permanent outsourcing, which we do not offer.
We already have a platform. Would you start from scratch?
No. In most engagements a cluster, a pipeline and half a portal already exist. We carry on with them and rebuild only what we can give a reason for rebuilding.
How do you make sure our team can run the platform afterwards?
Through the way we work, not through training at the end. Every change goes through a pull request from your team, runbooks are written at the first incident, and the operational handover is its own step in the plan.
Do you work with alternatives to Kubernetes?
Yes. Most of the work — delivery path, self-service, observability, handover — is independent of the runtime. Where Kubernetes is not the right choice, you hear that before the proposal.
How soon could you start?
We run only a few engagements in parallel, so availability is confirmed before a proposal is written. The conversation gives you a realistic start date, even when it is later than you hoped.
What if the analysis shows the platform is not the problem?
Then that is the result you get. Sometimes the constraint sits in ownership or in how teams are cut, and a platform project is the most expensive possible answer to that.
Talk about your project
A conversation about the state of your delivery path — and an honest answer on whether we are the right people for it.