About
Distributed Systems and Platform Engineer
I’m Bart. I’ve spent the past 15 years building backend systems and the platforms behind them across payments, video streaming, connected security, and AI products. The work taught me to treat failure as part of normal system behavior and to make failure paths explicit before they become production incidents. This page is the story behind that approach.
Path
From backend engineering toward platforms
Software was part of my world early. My father was a programmer, and during school breaks I would sit with him at work and learn how small programs were put together. As a teenager, I began taking on small projects to build websites for local events and community initiatives. Those projects taught me more than syntax. They taught me how to take an unclear need, make practical decisions, and deliver something people could actually use.
That hands-on start led into backend engineering for SaaS products and startups, then into systems with more demanding constraints. I worked on payments, multi-market commerce, video platforms, connected security, and AI products. As those systems grew, the most interesting questions moved below the surface of individual features: how work crosses service boundaries, what happens when dependencies fail, and how to keep the whole system reliable and operable in production.
Today I work across distributed systems, platform engineering, and reliability while staying close to implementation. I still build features, APIs, services, and workflows, but I see them as parts of a larger production system. That means making failure behavior explicit, building useful observability, planning for recovery, and creating foundations that help teams ship without making their systems harder to operate.
Philosophy
Principles that guide my engineering decisions
A set of working principles shaped by what actually holds up in production.
- 01Reliability is a product feature
- Availability, correctness under load, and predictable recovery are part of what a system delivers. They are not non-functional concerns added shortly before launch.
- 02Failure semantics should be explicit
- Timeouts, retries, idempotency, and partial failure should be designed deliberately and written down. Behavior under stress should be a decision, not an accident.
- 03Observability comes before guesswork
- Metrics, logs, and traces are first-class outputs. When something breaks, the goal is to read the system's signals instead of reasoning from intuition.
- 04Simple systems beat clever abstractions
- Abstractions earn their place when they remove real, recurring cost. Fewer moving parts mean fewer failure modes and a system that more people can safely change.
- 05Automation should reduce operational burden
- Tooling and paved paths should remove repetitive, error-prone work rather than add ceremony. Good automation makes the safe path the easy path.
- 06Developer productivity is an engineering multiplier
- Fast feedback, clear interfaces, and dependable platforms compound across every team that uses them. Improving developer experience improves everything built on top.
- 07Ownership extends into production
- A change is not finished when it is merged. Ownership includes understanding how it behaves in production, how it can fail, and how the team will know when it does.
Working with teams
Engineering is a shared responsibility
Own outcomes, not tickets
Tickets are inputs, not outcomes. I start with the problem the business and its users actually have, then work backward to the simplest useful solution. Good engineering is measured by the problem solved, not the amount of code shipped.
Make trade-offs visible
Good collaboration depends on making clear what a decision improves, what it makes harder, and what remains uncertain. I prefer direct communication over surface agreement that leaves important risks unresolved.
Leave the team stronger
Good engineering should improve more than the current feature. Better tooling, clearer boundaries, shared context, and thoughtful reviews make the next problem easier for everyone.
Experience
What production systems taught me
Different domains fail in different ways. Working across payments, ad tech, media, security, commerce, and AI shaped how I think about correctness, recovery, scale, and responsibility in production.
Payment platforms
Retries are part of financial correctness.
Built backend workflows around payment processing and external provider integrations. Delayed responses, duplicate callbacks, and partially completed operations showed me that recovery behavior is business logic, not technical cleanup.
Ad tech platforms
Raw data becomes valuable when it enables action.
Connected ML-backed services, large-scale web content analysis, and client-facing tools to automate campaign operations. Continuously changing, imperfect web data had to be transformed into classifications and controls that clients could rely on.
Video streaming platforms
Reliability is part of the viewing experience.
Helped evolve backend services for a large consumer video platform. Secure delivery, asynchronous processing, and operational continuity were not infrastructure concerns hidden behind the product. They directly shaped the experience users received.
Connected security systems
Software state can have physical consequences.
Developed backend capabilities for applications managing alarm control units and connected security devices. Commands, state transitions, and incoming events had to remain predictable because software actions affected real homes and businesses.
Multi-market commerce platforms
Market scale turns consistency into a platform problem.
Shaped backend systems supporting more than 40 storefronts across 16 countries. Product, pricing, search, and order workflows had to stay coherent while accommodating different markets, data requirements, and business rules.
AI-powered products
The model is only one dependency.
Built AI-backed workflows for creative products and fraud detection. Model providers, asynchronous processing, storage, cost, and latency all had to behave as parts of one production system without exposing that complexity to the user.
Off the clock
Beyond the systems
Outside my day-to-day work, I still tend to build things. I work on small products, contribute to open source, and write about what I learn, usually with a gourd of yerba mate nearby. Side projects give me room to explore ideas freely, while writing forces me to check whether I truly understand them.
Away from the screen, I create music, follow American football, and travel whenever I can. Discovering new places, cultures, and ways of thinking keeps me curious and gives me a perspective that goes beyond engineering.
Let's talk systems
Building a system that has to remain predictable under pressure?
I help teams shape the systems their products depend on, especially early on or when reliability becomes critical. I also write and speak about these problems. Tell me what you’re building and where it hurts.