Topic: Software Architecture

Flipster is our open source library for using OpenFeature safely in production. It came out of adopting trunk-based development, where feature flags stop being a nice to have and become the thing that lets a deploy and a release be two separate decisions.

It wraps the OpenFeature SDK behind an interface you can inject and test like any other dependency, and puts a circuit breaker in front of the provider. Defaults move out of the call sites and get declared once, in one place, so a degraded flag provider never becomes a production incident.

You finish a feature and you’re holding a hook, a helper, a type, and a stylesheet. Where do they go? For a while our answer was “it depends,” which is another way of saying nobody knew.

This is how we settled on one folder per feature, and how we stopped it from drifting back into a mess.

A React app crashes. Sentry tells you it crashed. It does not tell you whose crash it is. You can usually work that out. It’s just a step nobody should have to do by hand.

This is the story of how we taught our error boundaries to tag the team that owns the screen, so the report answers that question on its own.

A young engineer asked me a deceptively simple question. Years in the problem, and the answer came out as a fumble.

Every short definition slips. Architecture is not the diagrams, not a phase, not one person’s role. It is the practice of deciding which tensions to accept. Organizations and systems co-evolve. The architect’s value lies in building that capacity in teams, not owning every decision.

This is the answer that took almost four months to write: why the question resists a tidy definition, and why that resistance is the most honest signal we have about where architecture actually lives.

Five years ago, we invested in Domain-Driven Design. Conferences, workshops, consultants. The works.

The goal was simple: help humans navigate complexity. Make domain experts and developers speak the same language.

We had no idea those same boundaries would matter for something else entirely.

APIs need to stay stable even as the systems behind them keep changing. Each version becomes a contract that cannot move, while data models and requirements evolve around it.

Keeping everything working without slowing development is harder than it seems, and common approaches often break down once incremental changes start to accumulate.