Independent software engineering consultancy.
Based in Amsterdam. Working with engineering teams across Europe on their hardest technical problems.
Engineering-first consultancy
dplabs is an independent software engineering and technology consultancy based in Amsterdam, Netherlands.
The work focuses on difficult technical problems: systems that need to scale significantly, architectures that have become hard to change, teams that need to make better technical decisions, and organisations that want to adopt AI in a way that actually delivers value.
How I work
Most consultancies promise transformation. I prefer to focus on specific, tractable problems and solve them well.
Engagements start with an honest assessment of the situation — what the actual problem is, not necessarily what it’s been described as. From there, the work takes whatever form is most useful: advisory sessions, architecture reviews, hands-on implementation, or embedded work alongside your team.
I work with senior engineers and engineering leaders directly. The conversations are technical, direct, and aimed at producing outcomes rather than deliverables.
Technical background
Deep experience across the JVM ecosystem — Java and Kotlin with Spring Boot, Micronaut, and Quarkus. Extensive work with distributed systems: event-driven architectures, Kafka, message queues, and the operational complexity that comes with systems that communicate over unreliable networks.
Cloud architecture on AWS and GCP, Kubernetes, infrastructure as code, and the reliability engineering practices that keep production systems running under pressure.
More recently, substantial work in AI engineering: LLM integration, RAG systems, agentic architectures, MCP, and building AI tools that work reliably in production.
What I believe about engineering
The right solution is usually the simplest one that solves the actual problem. Complexity is a cost, not a signal of quality.
Engineering decisions made to avoid difficult conversations are always more expensive later. Direct feedback is a form of respect.
Reliable software comes from good systems — code reviews, testing, observability, runbooks — not individual brilliance under pressure.
A 200-page architecture document that sits on a shelf is worth less than a two-page ADR the team actually follows.
The system tells you things about your assumptions that no design review can. Observability and blameless retrospectives are how teams improve.
There are no universally correct architectural choices. Every decision has context. Understanding the trade-offs is more valuable than knowing the patterns.