Cloud & Platform Consulting · Amsterdam

Cloud and platform work
should not become
everyone's side job.

I help growing engineering teams turn AWS, Terraform, Kubernetes, CI/CD, and infrastructure ownership into clear, reusable capabilities, so developers can ship without waiting on ad-hoc platform support.

Useful when your company is growing, cloud complexity is increasing, and the same infrastructure problems keep coming back.

Let's talk → See how I work ↓
Professional profile photo

Senior Platform Engineer & Consultant

15yr network depth · 5yr platform consulting. From the wire up.

15yr network depth 40+ AWS accounts governed 40min → 5min deploys Amsterdam · remote NL/EU

When I'm usually useful

Most companies do not wake up one day needing "platform engineering."

They first notice smaller symptoms:

Deployments are slower than they should be.

Every team handles Terraform, CI/CD, or Kubernetes differently.

AWS accounts, permissions, networking, and cost controls are becoming harder to reason about.

Developers depend on one or two senior people for infrastructure changes.

Security and compliance expectations are growing.

Nobody fully agrees where platform, DevOps, product teams, and developers draw the line.

That is usually the moment where senior platform experience starts to matter. I help teams turn repeated infrastructure friction into clear ownership, reusable patterns, guardrails, and self-service workflows.

The problem

What most platform teams become

A sophisticated ticket queue. Developers ask "can you fix my pipeline?" - and the platform team says yes, because saying no feels unhelpful. Six months later the platform owns every pipeline, nobody understands the standards, and only a small group uses the platform.

What a platform team should be

An enabling team. One that turns repeated requests into self-service capabilities - with guardrails, policy, defaults, and auditability built in. Where the golden path is the easiest path, not a mandate.

The gap between those two states is usually not a technology problem. It's a clarity problem: unclear boundaries, no adoption measurement, no feedback loop between the platform and the teams it serves.

How I work

Scaling cloud infrastructure is mostly a people problem.

After building platforms at scale - and building my own applications on top of them - I've seen how often the real failure happens in the space between the platform team and the engineers who should be using it.

"The measure of a good platform is whether people use it without being told to."

- David Abarca, Mecha Consulting

"David is a beyond-exceptional team lead and a pleasure to work with. Particularly strong in improving the quality of technical teams and identifying areas of improvement. David significantly elevated the quality of our cloud offerings, coached our team toward excellence, and effectively guided closely related teams and internal customers."

Hessel Bakker, Enterprise Architect at Versatyle - worked together, October 2025

I work with engineering organisations as a senior individual contributor or embedded lead - helping define what the platform should own, build the capabilities that remove real friction, and create the feedback loops that keep it honest.

Golden paths

Reusable standards that make the right way the default way - not a policy document nobody reads.

Self-service capabilities

Common tasks available without a ticket, with guardrails, cost controls, and security boundaries built in.

Platform boundaries

Clear definitions of what the platform owns, what it enables, and what it hands back.

Adoption measurement

Feedback loops that tell you whether the platform is actually reducing developer toil.

Evidence from both sides of the platform

What developers experience

Self-service that actually works
Consistent tooling and patterns
Fast paths for common tasks
Confidence to ship without waiting

What organisations achieve

Faster delivery, fewer blockers
Stronger compliance and security
Lower cognitive load on teams
A platform people actually trust

Drove Backstage IDP adoption at Sdu - ran stakeholder alignment and ownership workshops to turn a tool deployment into an organisational change. Reduced fragmented knowledge across platform and product teams.

Built a Terraform module library adopted by 4–6 product teams - self-service provisioning where the correct path became the default path.

Running production on Hetzner with ArgoCD, Helm, Prometheus, Grafana, and Loki - and a bare-metal acceptance environment for the full CI/CD loop. I'm both the platform engineer and the developer it serves.

Multi-account AWS governance - Transit Gateway, network architecture, security boundaries across 40+ accounts.

Active in the CNCF and Platform Engineering communities in Amsterdam and at KubeCon.

Where I usually help

Most engagements start with one of these.

Every situation is different, but the underlying pattern usually isn't. If any of these sound familiar, it's worth a conversation.

No open platform role?

That is common.

Many growing engineering teams feel cloud and infrastructure pain before they create a formal platform role. The work often appears first as scattered DevOps tasks, slow delivery, unclear ownership, inconsistent Terraform, overloaded senior engineers, or AWS/Kubernetes complexity that keeps spreading.

If that sounds familiar, it is worth a short conversation even if there is no vacancy published.

If AWS, Terraform, Kubernetes, CI/CD, or infrastructure ownership is starting to slow your engineering teams down, send me a short note.

No formal role or project brief needed. A short email exchange is enough to see whether there is a real fit.

david.abarca@mechaconsulting.org