Student Assistant
Amsterdam University of Applied Sciences
–
Principal Engineer
– Current
Storyteq B.V. website ↗
I work on our video platform, which is really several products stitched together over the years. My job is making them work as one platform for the customers using them, the teams building them, and the people keeping them running. The work spans teams, systems, and leadership levels, connecting technical direction with delivery reality.
Rendering architecture
High-volume templated video where one creative fans out into many platform and market variants in long-running bursts across tenants.
The hard parts are template-level reuse and handling load that goes from idle to 50k+ requests per second, peaking near 80k.
Legacy stabilization
A tightly-coupled estate where shared databases, chained services, and deploy coupling meant one team's change could break another team's product.
Redrawing service and data boundaries with internal versioning and deprecation, so one team's release stops breaking another team's product.
Platform consolidation
Three product platforms merging into one. The hard part was the data: three models that had to keep talking to each other while old customers stayed on the old systems and new ones came up on the consolidated surface.
Twelve teams, five months, and architecture decisions that had to land without a major outage or a lost account.
Architecture practice
Establishing the decision practices the org now runs on: ADRs, RFCs, and design reviews, now mandated org-wide.
Pushing end-to-end ownership of each domain into the teams that build it, with feature flags and CI/CD as the default delivery posture.
Technical strategy
Helping shape the technical side of every roadmap at quarterly planning, with each domain's lead carrying the deep work.
Keeping twelve teams aligned on direction as the platform comes together, so the calls made in one domain don't break the others.
How I work
- I treat decisions as artefacts. If it's worth doing, it's worth an ADR. And if no one can find the ADR later, the decision didn't really happen.
- I'd rather make a domain boundary clear than perfect. Most architecture pain comes from fuzzy ownership, not bad code.
- I work hardest on the parts of a system that only a few people understand. Knowledge concentrated in heads is a load-bearing dependency, and I'd rather pay it down than route around it.
- I connect technical direction with delivery reality. Which mostly means saying no to clean architectures that won't survive contact with how teams actually ship.