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.
BOOK A FIT CHECKWhy 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.
How it shows up day to day
Six situations we meet again and again in platform work. The more of them fit, the less another target-picture discussion will do for you.
- A new service takes weeks to reach production. Most of that time is spent waiting on infrastructure, not writing code.
- Every team describes its infrastructure differently. Moving between two repositories feels like moving between two companies.
- The platform team works a ticket queue instead of building self-service. The queue keeps growing anyway.
- A cluster upgrade gets postponed because nobody can say what will stop working afterwards.
- Onboarding means somebody sets up the development environment in person. There is no written path to follow.
- A developer platform was started, and nobody decides whether to finish it or switch it off.
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.
How an engagement runs
Four steps, in this order. You can stop after the second one and still keep a result you can work from.
Fit check
A conversation about what is not working right now, and about whether we are the right people for it. If we are not, you hear it in that call.
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.
Engagement models
Four ways into the work. Which one fits is decided in the fit check; the pages behind them state scope, duration and price in full.
Analyse first
When it is not yet clear where the constraint sits: a fixed-scope analysis that ends in a prioritised roadmap.
Stabilise first
When an existing platform is actively doing damage and things have to calm down before anything is rebuilt.
Build the platform
When a Kubernetes environment should become a platform your team runs on its own — with a fixed start and end date.
Ongoing engagement
Several months with a fixed number of days per week, where platform work needs an experienced hand for longer. Scope and term are set case by case.
What you can check
Plainly: there is no figure from a client engagement on this page. What we built before was never measured in a way that would prove anything here, and we will not invent numbers to fill the gap.
A number belongs in this space. There is none: no earlier engagement measured its effect in a way that would prove anything here. As soon as a client releases a measurement, it goes here — not before.
References
What we have worked on, described without metrics, because we never collected any.
Delivery model
Who does the work, who reviews it, and where delivery accountability stays.
Articles
How we think about platforms, pipelines and operations — public, and at full length.
Relevant case studies
Case studies for this work, with context, intervention and handover. Each one appears only once the client has released it in writing.
No case study for this work is published yet. The first one is being written and is waiting on the client's release.
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 fit check 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.
Is the platform your bottleneck?
A conversation about the state of your delivery path — and an honest answer on whether we are the right people for it.