Engineering teams with manual releases, production instability or a time-to-market that slows the business. Typically European scale-ups and SMBs maturing their delivery, or enterprise companies aligning standards across teams.
I build CI/CD pipelines, Infrastructure as Code and delivery standards the internal team can actually maintain. I work on tech and on accountability and ownership: without the latter, the former doesn't last.
Lead time down 40-60% on covered flows, more frequent and less dramatic releases, fewer post-release incidents and a technical baseline the internal team can run on its own.
End-to-end pipelines with quality gates, automated tests and rollback. Goal: frequent releases without compromising stability.
Versioned, reproducible and auditable infrastructure. Less drift, fewer manual tasks, more control.
Container platforms on Kubernetes/AKS with scaling, observability and deployment strategies aligned with your product.
Restructured release flow for distributed teams with shared policies and full dev-to-prod automation.
Transitioned from manual operations to modular IaC with review workflows and governance standards.
Built an AKS platform with observability and deployment strategy to support growth and reliability.
How I plug into a Dutch engineering team without slowing it down.
Dutch teams tend to be flat and direct, and so is the way I work: next to your engineers, not above them. Decisions are discussed openly and written down, not handed over as a slide deck.
Many Dutch tech teams are international. Pipelines, IaC modules, READMEs and runbooks are written in English, so onboarding a new hire doesn't depend on who happens to be in the room.
A common setup: a few days a week alongside your team as fractional Azure DevOps / platform engineer, with on-site days in Amsterdam when it helps. Scope and duration agreed upfront.
When releases need too many people and too many hours, when production is touched with fear, when the same bug keeps coming back in different environments. The clearest signal isn't technical: it's how slowly the team can accept new business requests.
Both, and they're usually inseparable. Well-crafted pipelines without ownership collapse in months; ownership without automation doesn't scale. I work on delivery standards, release accountability and internal team enablement, not just on YAML.
You start from the biggest pain point. If releases are the bottleneck, CI/CD first; if infrastructure changes by hand and nobody can rebuild it, IaC first; if customers always find the issues first, observability first. Three useful fronts, but not all at once.
Lead time drops (typical range 40-60% on the first automated flows), releases get more frequent and less dramatic, post-release incidents fall on covered flows. The metric that matters isn't peak speed, it's predictability.
If your team ships too slowly or with too much risk, we can define a practical operating plan.
Based in Amsterdam. Easy to meet in person in NL or on video for EU clients.