About
Eleven years of making systems less exciting
I am a software engineer in Rotterdam. I get called in when something is slow, fragile, expensive, or when nobody wants to deploy it on a Friday afternoon — and I leave behind something the team can explain without me.
I wrote my first line of production code in 2014 at a three-person studio in Delft, and I broke production for the first time about six weeks later. Both of those things turned out to be formative. The studio had no staging environment and one customer who called on Saturdays, so I learned early that "it works on my machine" is not a sentence you want to say to somebody whose business is currently down.
Since then the work has mostly been the same shape, at a larger scale: payments infrastructure at Booking.com, a long and partially regrettable monolith split at PostNL Digital, and since 2020 independent consulting for teams whose systems have grown faster than their understanding of them. I have been the first engineer, the tenth, and the one brought in at the end to write the post-mortem.
What I actually do is narrower than "full-stack engineer" suggests. I profile things, I read query plans, I delete code, and I write the runbook. A typical engagement starts with a week of measurement and ends with fewer moving parts than it began with. I am genuinely happy when the outcome is boring: a dashboard that loads, a deploy that takes ninety seconds, a queue that drains.
I am not the person you want for a greenfield rewrite. I have done two, and both times the honest summary was that we could have fixed the original in a third of the time. I am also not a Kubernetes evangelist, or a Rust evangelist, or any other kind — I use what fits the workload and I will happily argue that the boring option is correct.
How I got here
-
2020 — present
Independent engineer & consultant
Rotterdam, NL
Two engagements a quarter, usually performance work, database cleanups or rescuing a service that has become frightening to deploy. Written diagnosis first, then fixed-scope work in weekly increments.
-
2018 — 2020
Staff engineer, platform
PostNL Digital · Rotterdam
Led the platform group through a monolith split, then spent most of the following year undoing the parts that were not worth the operational cost. Wrote the on-call rotation that is, as far as I know, still in use.
-
2016 — 2018
Senior backend engineer
Booking.com · Amsterdam
Payments infrastructure. I learned more about idempotency, reconciliation and the difference between "exactly once" and "at least once, but we deduplicate" than I ever wanted to know.
-
2015 — 2016
Backend engineer
Mirabeau · Amsterdam
Agency work: twenty-odd client projects in eighteen months. The best possible training in reading unfamiliar code quickly and deciding what not to touch.
-
2014 — 2015
Junior developer
Studio Kade · Delft
First job, first production outage, first runbook. Three people, one server, and a surprisingly good education in doing a lot with very little.
Capabilities
What I am actually good at
Four areas where I can be useful on day one, rather than after a month of onboarding.
Performance & reliability
- Profiling and load testing under production-shaped data
- Core Web Vitals: measurement, budgets, regression policy
- Capacity planning and cost reduction
- On-call design, alerting that does not cry wolf
- Incident review that produces changes, not documents
Data & databases
- PostgreSQL schema design, indexing and query tuning
- Migrations without downtime on live tables
- Replication, backups, and actually testing the restore
- Analytical workloads in ClickHouse
- Caching strategy where it pays and where it lies
Platform & operations
- Linux, containers, and knowing when not to use them
- CI/CD that a new joiner can read in one sitting
- Observability: logs, traces and metrics people use
- Infrastructure as code without a framework religion
- Deployment strategies with a real rollback path
Product engineering
- TypeScript, Go and Rust in production
- Design systems and token architecture
- Accessibility as an engineering constraint, not an audit
- API design and versioning that survives clients
- Technical writing: runbooks, decision records, RFCs
Working together
What an engagement looks like
I do not start with a proposal. I start by finding out whether the problem is what it looks like.
Step 01
A short call
Thirty minutes. You describe the symptom, I ask what has already been tried and what the constraint is (time, money, or politics). Sometimes the answer is that you do not need me.
Step 02
A written diagnosis
One paid week. I read the code, run the queries and measure the thing. You get a document: what is wrong, what it costs, and three options with honest trade-offs. No obligation to continue.
Step 03
The work
Weekly increments with fixed scope. You get commits, not slide decks. Your engineers work alongside me on purpose — the point is that they can maintain it after I leave.
Step 04
Handover
A runbook, a decision record for anything contentious, and a list of what I deliberately left alone. If it needs a second phase, you will know why before I invoice for it.
Off the keyboard
The rest of the week
Partly to prove I am a person, partly because these things make me better at the first part.
Rowing
Wednesday and Saturday mornings on the Nieuwe Maas, in a boat with eight other people and one very loud cox. It is the only activity I have found that is impossible to do while thinking about a query plan.
Film photography
A Pentax K1000 that has outlived three laptops, mostly Portra 400 and mostly bad frames. Thirty-six exposures forces a kind of deliberateness that I try, with mixed success, to bring to code review.
Sourdough
Started in 2020 like everyone else, still going. It is a long-running system with a single point of failure, an unpredictable latency profile and no observability, which may explain why I find it relaxing.
Sound like a fit?
Tell me what is slow, fragile or frightening to deploy. I answer every message myself, usually within a working day, and I will say no if I am not the right person.