Your stack is a liability, not an asset

There’s a moment early in every project where the technology feels like a collection of superpowers. A new database that scales infinitely. A framework that does everything. A queue, a cache, a search engine, a serverless runtime — each one a capability you didn’t have yesterday. It’s intoxicating, and it’s a trap, because you’re counting the powers and ignoring the bill. Every one of those things is not an asset you own. It’s a liability you now maintain.

The reframe that changes how you build: a technology’s cost isn’t what it does for you on a good day. It’s what it demands from you on a bad one — the upgrade that breaks, the outage at 3 a.m., the security patch, the one engineer who understood it leaving, the documentation that rotted. You pay that rent for as long as the thing is in your system, whether or not you’re using its fancy parts.

This is why boring technology is quietly a superpower. Not because old tools are better — often they’re clumsier — but because they’re known. A decade-old database has had its failure modes mapped by a million people before you. When it breaks, the answer is the first result on a search, not a thread of five people with the same unsolved problem you have. Boring means the surprises have already happened to someone else. Novelty means you’re the one discovering them, in production, at the worst time.

Ask of every new piece: what happens the night this fails and I’m the only one awake? If you don’t like the answer, you don’t want the technology.

None of this means never adopt anything new. It means spend your novelty budget deliberately. You get a small number of genuinely new, genuinely risky technologies you can afford to babysit — pick them for the one or two places where the new capability is the actual point of your product, the thing that makes it different. Everywhere else, be aggressively boring. Use the database everyone uses. Use the framework with the biggest crowd. Save your weirdness for where weirdness earns its keep, and let the rest of your system be forgettable — because forgettable is what lets you sleep.

The best stacks I’ve worked with weren’t the most impressive on paper. They were the ones nobody had to think about. Fewer moving parts, each one dull and dependable, chosen so that the interesting problem could stay the product itself rather than the machinery underneath it. That’s the real goal: not a stack that shows off what you know, but one that asks almost nothing of you when you’re not looking — so all your attention is free for the thing that actually matters.