The Case for Boring Software

Every time we evaluate a new technology, someone on the team asks: “Is this just exciting, or is it actually good?”

It’s a harder question than it sounds. In software, exciting and good are often in tension. New frameworks promise to solve problems the old ones created. New databases offer trade-offs that look like pure wins until you’re three years into production. New deployment patterns reduce one kind of complexity while quietly introducing another.

The most reliable systems we’ve built share one characteristic: the technology inside them is aggressively uninteresting. PostgreSQL. Docker. Nginx. Things that have been running in production for decades, that have absorbed ten thousand edge cases into their documentation, whose failure modes are well-understood and whose communities are large enough that someone has already answered your question on Stack Overflow.

We call this “boring software,” and we’ve come to treat it as a feature, not a limitation.

What boring actually buys you

When the technology is boring, the problems are usually yours. A mysterious PostgreSQL crash in 2025 is almost certainly a misconfiguration, a bad query, or a resource limit — not a framework bug. That means your debugging process starts at the right place. You don’t spend hours wondering if you’ve hit an undocumented edge case in something that was released last year.

When the technology is boring, onboarding is faster. A new engineer who’s never seen your codebase has almost certainly seen Nginx before. They can read the config, understand what it does, and make changes with confidence. That confidence compounds over time.

When the technology is boring, your future self can read the commit history and understand it. Not “what did this abstraction used to do before the library changed its API,” but “ah, we added this index in March because the query was slow.”

The hidden cost of interesting

We’ve shipped features that were interesting to build and expensive to maintain. A bespoke caching layer that saved 200ms but required specialist knowledge to debug. A clever abstraction that reduced boilerplate until the underlying framework changed and suddenly everything was boilerplate again, plus migration debt.

The cost of interesting software isn’t paid when you build it. It’s paid at 11pm when something breaks and the person on call needs to understand what they’re looking at.

None of this means never use new tools. It means being honest about why you’re reaching for one. Is it solving a real problem that boring alternatives can’t? Or is it just more interesting?

Usually, boring is enough. And enough, done reliably, beats brilliant done unreliably every time.