Platform Engineering

Platform engineering is about building the internal platform other engineers build on top of — so each team isn’t solving the same infrastructure problems independently, and provisioning a new service doesn’t mean re-deriving how deployment, secrets, and networking are supposed to work.

In practice: GitOps-driven Kubernetes platforms, self-service patterns via Helm and FluxCD, and Infrastructure-as-Code that’s reusable across projects rather than bespoke per team.

Problems this usually starts from

These are the kinds of things that usually prompt someone to get in touch:

• Every team re-solves the same deployment, secrets, and networking problems independently.
• Provisioning a new service means copying and adapting someone else’s setup and hoping it’s current.
• There’s no self-service path, so every change routes through one overloaded team.
• Kubernetes is running, but nobody’s agreed what “the platform” actually includes.
• Infrastructure-as-Code exists, but it’s bespoke per project rather than reusable.
• Standards exist on paper but aren’t enforced anywhere in practice.
• Onboarding a new engineer means walking them through undocumented tribal knowledge first.

What an engagement looks like

Starts with understanding what teams are actually building against today — which parts of the platform are genuinely shared, and which are duplicated per team without anyone deciding that on purpose. From there: GitOps-driven Kubernetes platforms, self-service patterns via Helm and FluxCD, and Infrastructure-as-Code that’s reusable rather than copy-pasted.

Scope is either a fixed piece of work (standardising one part of the platform, a specific migration) or an ongoing placement building it out over time. Deliverables are things teams can actually build on: documented, reusable modules and patterns, not a one-off cluster only I understand.

Typical work looks like: Helm charts and FluxCD Kustomizations that make “add a new service” a pull request rather than a ticket to another team; RBAC and namespace conventions that still hold up once the platform’s grown past the first few teams using it; and Terraform modules written to be reused, not copied, edited, and quietly diverged from the original.

Engagements typically run anywhere from a few days for standardising one specific piece up to several months for building the platform out over time — there’s no minimum contract length, and scope can start small and grow once it’s clear the working relationship fits.