2 min read
Why we choose boring technology (most of the time)
Proven tools let teams spend their innovation budget on the product instead of the plumbing. Here is how we decide when something new is worth it.
Every engineering team has a limited budget for novelty. Each unfamiliar database, framework or deployment model consumes some of it, in learning, debugging, hiring and operations. We prefer to spend that budget on the part of the system that makes our clients’ products different.
What “boring” means to us
Boring technology isn’t old or bad technology. It’s technology whose failure modes are well understood:
- PostgreSQL rather than the database that launched last quarter.
- A well-structured monolith before a fleet of microservices.
- Server-rendered pages before a complex client-side state layer.
- Managed cloud services before self-hosted clusters.
These tools have large communities, mature documentation and many engineers who already know them. When something breaks at 2 a.m., the answer is usually one search away.
The hidden costs of novelty
New tools rarely fail on day one. Their costs show up later, often after the people who chose them have moved on:
- Operational unknowns. Backups, upgrades, monitoring and failure recovery all need to be learned from scratch.
- Thin ecosystems. Fewer libraries, integrations and answers mean more custom code to own.
- Hiring friction. Every niche technology narrows the pool of people who can work on the system.
- Upgrade churn. Young projects change quickly, and keeping up with breaking changes is real work.
- Fragmentation. Two ways of doing the same thing doubles the knowledge a team needs to carry.
None of these costs appear in a demo. All of them appear in a maintenance budget.
When new is worth it
We do adopt new tools, deliberately. Before introducing something new, we ask:
- Does it solve a problem we actually have, rather than one we might have someday?
- Is the gain large, an order of magnitude better rather than marginally nicer?
- Can we contain it? If it disappoints, can we replace it without rewriting the system?
- Can the client’s team own it after we hand over?
If the answer to all four is yes, we run a time-boxed spike and write down what we learned in a short decision record. AI tooling is a good example: we adopted it quickly where it clearly improves outcomes, behind evaluation suites and clear boundaries, so it can be swapped or removed without touching the rest of the system.
Boring isn’t stagnant
Choosing proven tools doesn’t mean standing still. We keep systems current with small, frequent upgrades:
- Dependencies are updated continuously with automated pull requests and a test suite we trust.
- Major versions are scheduled as planned work, not emergencies.
- We favour long-term-support releases for runtimes and databases.
- Every significant technology decision is recorded, so the next team knows why, not just what.
The result is a system that stays modern without ever needing a “big rewrite”.
The payoff
Products built on proven foundations are cheaper to run, easier to hire for and safer to change. More of the budget goes into features users notice, and fewer surprises reach production.
It isn’t glamorous. It’s how software gets built to last. If you’re inheriting a system built on too many experiments, we can help you simplify it.