The hidden cost of chasing what's new
Every year brings a new framework promising to fix everything wrong with the last one. Some of these tools are genuinely good. Most of them add a second cost that rarely shows up in the pitch: the cost of not being boring.
"Boring" technology — meaning mature, well-documented, widely adopted — isn't a lack of ambition. It's a deliberate tradeoff, and for most client work, it's the right one.
What "boring" actually buys you
Predictable failure modes
Mature tools have been broken in every way they can be broken, by thousands of other teams, years before you touched them. When something goes wrong, the answer is usually a search away — not a GitHub issue you have to file yourself and wait on.
Hireable, replaceable expertise
A stack built on well-known, widely-taught technology means the next developer — whether that's someone we bring in or someone the client hires later — doesn't need months of ramp-up just to understand the codebase.
Long-term maintainability
Software has to survive past the initial build. A framework that's exciting today but abandoned in three years leaves the client holding a maintenance liability, not an asset. Longevity is a feature, and it's one you can only judge by track record.
Lower total cost of ownership
New technology often looks cheaper up front — less code, faster prototyping — but the cost shows up later in hiring difficulty, breaking changes, and thin documentation. Boring technology front-loads the learning curve and back-loads the stability.
Where we deliberately break this rule
Boring-by-default doesn't mean stagnant. We adopt newer tools when the upside is clear and the downside is contained:
- Next.js's App Router — genuinely faster for the kind of content-heavy, SEO-sensitive sites we build, and backed by a company with a strong incentive to keep it stable.
- Tailwind CSS — a newer approach to styling, but with enough adoption and stability now that the "will this still exist in three years" question is answered.
- AI-assisted development tools — new, fast-moving, and genuinely useful, but used as an accelerant on our own process, not as untested infrastructure we hand to a client.
The pattern: we adopt new tools where we can absorb the risk ourselves, and stay conservative on anything the client has to run and maintain for the next decade.
The actual question to ask
Not "is this technology exciting?" but "will this still be a reasonable choice in five years, and can someone other than the original author maintain it?" Most trend-driven technology choices fail that second question quietly, long after the person who chose it has moved on.
Building something that needs to last, not just launch well? That's the conversation worth having before the tech stack gets picked.