Architecture
Decisions that shape how a product grows: micro-frontends, backends-for-frontend, shared libraries, configuration over code. Each one comes from a system I worked on, with the trade-offs that came with it.
Backend for frontend: one API per kind of client
At Doktor24, patients, practitioners and configurators needed very different things from the same platform. Node.js BFF services gave each client an API shaped for it.
Dashboards from JSON schemas: replacing spreadsheet reports
At LeoVegas I built a Node.js service and a schema-driven dashboard framework with pluggable database connectors, so product managers could stop building reports by hand.
Micro-frontends with Module Federation: what we gained and what it cost
At Doktor24 we split a healthcare web platform into micro-frontends so teams could ship on their own schedule. Here's the reasoning, the trade-offs, and when I wouldn't do it.
One shared TypeScript library for every service, without a god library
At KitchenSync I designed a shared TypeScript library with more than 16 modules used across the whole platform. Here's how to keep something like that useful instead of dangerous.
Rules as data: onboarding customers without shipping code
At KitchenSync every restaurant had its own accounting rules. Moving those rules out of code and into configuration changed how we onboarded customers.
Turning a mobile app into a white-label SaaS
How we refactored Doktor24's mobile app so partners could get their own branded version from configuration, with a CI/CD pipeline that builds each brand.
Other topics
- AI in production9LLM features that survive real users: contracts, evals, cost.
- Agents & automation3Agents, MCP servers and bots that do real work.
- Architecture6Frontend and backend structure that scales with the team.
- Backend, security & infra3Auth, data pipelines and the infrastructure under it all.
- Leadership & delivery2Leading small teams and shipping under constraints.