Student Assistant
Hogeschool van Amsterdam
–
Principal Engineer
Storyteq B.V.
– Current
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. My work spans teams, systems, and leadership levels, connecting technical direction with delivery reality.
Key Achievements
- – Leading the platform rollout across regions, existing customers, and internal product teams — sequencing migrations and coexistence so live customer workflows kept running through the cutover
- – Stabilizing a tightly-coupled legacy 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 so teams can ship independently
- – Unifying three overlapping products into one platform — federation first so existing customers kept the surface they knew, moving toward a shared core that gives every customer the best of what each product had
- – Designing the rendering architecture for high-volume templated video — one creative fans out to many platform and market variants, in long-running bursts, across tenants — focused on fair scheduling, template-level reuse, and deadline-aware queueing
- – Establishing the architecture-decision practices the org now runs on — ADRs, RFCs, and design reviews adopted across most teams — and pushing end-to-end ownership of each domain into the teams that build it
- – Driving delivery safety as the default — feature flags, CI/CD discipline, and reliability ownership as the way teams ship, not the exception
Approach & Impact
- – 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.
Technology Stack
Architecture:
System Design Microservices Microfrontends REST APIs Documentation
Frontend:
Vue Angular React TypeScript
Backend:
Node.js Java PostgreSQL MySQL GraphQL
DevOps & Cloud:
Docker Kubernetes Helm GCP CI/CD Pipelines
Leadership:
Team Leadership Mentoring Technical Strategy Stakeholder Management