The Case for Boring Software
Exciting technology choices feel good in the moment. Boring ones age gracefully. Here's how we think about the tradeoff.
There's a particular kind of meeting that happens at the start of every greenfield project. Someone suggests using the new framework everyone's excited about. The energy in the room goes up. A few heads nod.
This is usually where problems start.
Exciting vs. durable
New tools are exciting because they solve real problems. They're also unproven at scale, lightly documented, and staffed by a community that'll move on when the next exciting thing arrives.
Boring software — Postgres, boring REST APIs, server-rendered HTML, proven deployment pipelines — doesn't generate conference talks. It also doesn't page your on-call at 2am because a dependency broke.
The compounding cost of novelty
Every non-standard choice you make is a tax on every future engineer who joins the project. They have to learn your custom thing instead of applying what they already know. Debugging gets harder. Hiring gets harder. Onboarding takes longer.
This isn't hypothetical. We've inherited projects built on experimental tooling that the original team thought was clever. The original team had moved on. The documentation was thin. The community had moved on too.
When to be boring, when not to be
Boring-by-default doesn't mean never taking bets. It means being intentional about where you spend your novelty budget.
The infrastructure layer? Boring. The core data model? Boring. The deployment process? Boring.
The feature that's your actual differentiator? That's where you can afford to be interesting. That's where the investment pays off.
The products that last
The best software we've worked on shares a pattern: aggressive conservatism in the foundation, genuine innovation in the product layer. The boring parts mean the team can focus on what actually matters to users.
That's the bet we make every time.