There's a reliable way to spot software built to impress its builders rather than serve its owners: count the technologies. The system with four databases, two queue systems and a framework released last spring wasn't architected — it was collected. And the collector rarely pays the maintenance bill.
The real cost of exciting technology
New technology charges you three times. First in unknown unknowns: the failure modes nobody has blogged about yet, discovered at 2am in your production system. Second in hiring: every exotic choice shrinks the pool of people who can maintain the system and raises their price. Third in longevity: this year's exciting framework is a coin-flip to be abandoned within five years — proven tools have already survived their extinction events.
The three charges compound each other. The exotic database fails in an undocumented way, which is survivable — except the one engineer who understood it left in spring, and the replacement search is now in month four, because the candidate pool for that particular skill is a rounding error. Meanwhile the framework it depends on announced its "exciting new direction," which is vendor-speak for a rewrite of everything you built on the old one. None of these were separate risks; they were one risk, purchased three times.
These costs land after the agency leaves. That's precisely why agencies are structurally tempted by exciting technology — the résumé benefit is theirs, the maintenance bill is yours. Aligning those incentives is a contract-design problem as much as an engineering one: it's part of why we warranty our work and offer to operate what we build.
How the collection happens
Nobody sets out to build an unmaintainable system; it accretes through individually defensible decisions. An engineer wants a technology on their CV, and the project is the only place to get it. A conference talk makes an architecture designed for a company with a thousand engineers look like best practice for a team of six. A microservices diagram feels more professional than an honest monolith. Each choice adds one moving part, and moving parts multiply: two databases don't cost twice one database — they cost the second database plus the synchronisation between them, forever.
The defence is a boring rule applied at review time: every technology beyond the default stack must buy its way in with a measurable requirement the default cannot meet. "It's more scalable" doesn't count without a number. "We might need it later" is a reason to add it later. The burden of proof sits with novelty, never with the boring choice — because only one of them has a track record to point at.
Innovation is a budget. Spend it on your product, where customers can see it — not on your infrastructure, where only your engineers can.
Boring ≠ old
Boring doesn't mean legacy. PostgreSQL, TypeScript, React, mainstream cloud services — these are modern, actively developed and extremely capable. What makes them boring is that their sharp edges are documented, their failure modes are known, and a million teams have already hit the problems you're about to hit. Boring means predictable, and predictability is what you're buying when you pay senior rates.
There's a hiring signal hidden here that owners consistently misread. Junior engineers chase interesting stacks; senior engineers chase interesting problems and pick sleepy tools on purpose, because they've personally paid the 2am bill for excitement. A team that sells you a boring architecture isn't being unambitious — it's showing you its scars. The ambition belongs in what the system does, not in what it's made of.
The discipline has a corollary: when we do spend the innovation budget — as with AI systems, where the frontier genuinely moves quarterly — we isolate the exciting part behind boring interfaces, keep it swappable, and wrap it in evaluation. The blast radius of novelty should be a module, never an architecture.
In practice that means the model provider sits behind an interface the rest of the system doesn't know about, so swapping it is a config change, not a migration. It means an evaluation harness that scores every candidate model on your real cases, so the swap decision is a measurement, not a fashion statement. The exciting part stays exciting — it just isn't allowed to make the rest of the system interesting.
The default stack, and how to change it
The practical tool behind all of this is a written default stack: the short list of technologies a new system uses unless someone proves otherwise. One primary database. One backend language the whole team reads. One frontend framework. Managed cloud services over self-hosted anything — the boring choice in operations is paying the cloud provider to carry the pager. The list fits on an index card, and that's the point: every addition to it should feel expensive, because it is.
Changing the default is allowed — through the front door. A short written case: the requirement the current default can't meet, the number that proves it, the migration path in and the exit path out. Then a trial in something non-critical before anything customer-facing depends on it. Teams that run this ritual adopt perhaps one new technology a year, deliberately, and it sticks. Teams that don't, adopt five by accident and keep two — the other three remain in production anyway, half-migrated, charging rent forever.
Questions to ask your next vendor
Who will maintain this in year three, and what will they cost? How large is the hiring pool for this stack — and what happens to our timeline when one of these frameworks is abandoned? Why this second database, in numbers? What does the on-call runbook look like, and could an engineer who didn't build the system follow it? If the answers are hand-waves, the architecture is a liability wearing a demo.
Boring technology is how software stays an asset instead of becoming a science project with a login page — which is to say: it's a luxury your business can afford precisely because it doesn't look like one. The premium isn't in the tools. It's in the restraint.