Boring on Purpose: The Tech Choices That Let One Person Sleep
There is a particular romance to a new stack. A framework that promises to delete a whole category of problem, a database that does the thing the old one couldn't, a deploy tool with a launch video that makes your current setup feel like a fax machine. I feel the pull as much as anyone — I've been an engineer for thirteen years and the appetite for the new doesn't fade, it just gets more expensive. Because when you're a one-person company, every technology you adopt is something you, alone, have to operate at 3am. So I choose boring on purpose.
This isn't a lack of curiosity. It's a budget. A team can afford to carry an exciting dependency because someone on it has read the source, fought the edge cases, and can be paged when it breaks. A solo founder has exactly one of those people, and he'd like to sleep. So "is this interesting?" is the wrong first question. The right one is "if this wakes me up in eighteen months, will I be glad I picked it?"
Every dependency is a 3am phone call
The cost of a tool isn't what it takes to adopt it; it's what it takes to operate it on its worst day. New technology fails in new ways — ways that aren't on Stack Overflow yet, ways the maintainers are still discovering, ways you'll be debugging alone with the docs that don't quite cover your case. Boring technology has already had its worst days, in public, with thousands of people present. Its failure modes are catalogued. Your weird bug is somebody else's old, answered question. That archive of other people's pain is, for a solo operator, a feature you cannot buy any other way.
So my defaults are aggressively dull: Postgres until it genuinely can't, Node and Python because I trust them at 3am, plain deploys over clever orchestration, a managed database over one I run myself. None of it would make a conference talk. All of it means that when something breaks, I'm fixing a known problem with a known shape instead of becoming the maintainer's first bug report.
Spend your novelty budget on one thing
Boring everywhere would be its own mistake, though, because a product that takes no risks isn't differentiated — it's just smaller. The move isn't to avoid the new; it's to spend a strict novelty budget, and spend all of it in one place: the thing your users actually pay for. For me that place is applied AI. That's where I'll happily run ahead of the documentation, eat the operational pain, and accept that I'm on the frontier, because that's the part of the product that's supposed to feel like the future.
Everywhere else, I pay cash. The auth is boring so the AI can be interesting. The database is boring so the retrieval pipeline can be strange. You get one frontier at a time before the operational surface gets bigger than one person can hold, and the discipline is refusing to open a second one just because something shiny shipped this week.
Novelty you can't staff is a tax you pay alone, in the middle of the night, for years.
Boring is a feature for users too
There's a quieter payoff that took me a while to see: boring technology is usually more reliable for the person using the product, not just the person running it. The mature database loses less data. The proven framework has fewer surprising edge cases. Stability isn't the absence of ambition — it's the thing that lets ambition survive contact with real users. On VoltExam and CapitalGains, the parts I'm proudest of are the parts nobody notices, because they simply work every time. Boring infrastructure is how a one-person product earns the kind of trust I keep writing about — the trust that lives in the cases the demo never shows.
When I do reach for the new thing
None of this is a vow of permanent caution. I do adopt new tools — just deliberately, and with a question I make myself answer first: what does this let a user do that they couldn't before, and am I willing to be its on-call engineer? If the honest answer is "it's nicer for me" but not "it's better for them," it goes on a someday list and I move on. If the answer is yes, it earns the novelty budget, and something else has to get more boring to pay for it. The goal was never to use the least interesting tools in the world. It's to make sure the only exciting thing in the building is the product — and that everything holding it up is dull enough to sleep through.
More writing
- Charge on Day One: What a Price Tag Taught a Solo Founder
- The Distribution Problem: Why Shipping Was Never the Hard Part
- The Smallest Honest Version: How I Decide What to Build
- The One-Person Stack: How a Solo Founder Covers a Team's Surface Area
- The Fallback Is the Feature: Designing AI That Never Hard-Fails
- The 2%: Why Edge Cases Decide Whether People Trust Your Product
- Going Independent: Notes From the First Stretch