Every few years software engineers converge on a new paradigm, and suddenly it feels like you’re falling behind if you haven’t adopted it. Microservices. Event-driven architecture. Server-side rendering coming back around. Each of these emerged because real teams hit real scaling problems and needed better solutions. Before adopting any of them, ask whether your team actually has the specific problem the pattern was designed to solve.

Microservices are a good example of the mismatch. They solve coordination challenges that surface when multiple teams need to deploy independently against a shared system. That’s a genuine problem at a certain scale. On the other hand, I’ve spoken with engineers from startups with a team of five that spent months decomposing a perfectly functional application into services, because it felt like it would be irresponsible not to adopt it (even when nobody on the team was actually blocked by the monolith).

A small company I worked at ran a highly successful, monolithic application for years – without regret. Every architecture decision we made started with a real constraint we were actually facing: keeping the system simple enough that any engineer could debug production issues without calling for help, building internal tooling so a small team could operate without heroics. Those choices compounded over years in ways that served our specific needs very well.

Some of the best engineering decisions I’ve made came from recognizing we didn’t have the problem a pattern was meant to solve and putting the time into something that actually moved the needle for our team and our clients.

What’s an “unsexy” architecture decision that ended up being one of your best?