Argues the 2026 version of the classic mistake isn't picking Cassandra over Postgres — it's a four-person startup running a vector DB, inference gateway, agent framework, feature store, and LLM observability stack to ship a search box. LLMs have collapsed the authoring cost of adopting new tech without touching the operating cost, making McKinley's token discipline more relevant, not less.
McKinley's original thesis: each project gets roughly three innovation tokens, and every non-boring technology adopted spends one. Boring tech has known failure modes and documented recovery paths; novel tech ships unknown unknowns that surface at 3am. He proposes a simple gate — write down what problem it solves, what you'd use instead, and what happens when it breaks — and argues most candidates fail before the second bullet.
By resurfacing the 2015 essay for the fourth or fifth time in a decade, the submitter is implicitly endorsing that McKinley's framing still describes the failure mode teams keep repeating. The 293-point score suggests the HN audience agrees the discipline remains under-practiced.
Dan McKinley's 2015 essay *Choose Boring Technology* is back on Hacker News with 293 points and climbing. It's the fourth or fifth time in a decade it's cracked the front page. The thesis hasn't changed since he first wrote it as Etsy's principal engineer: every team gets a small budget of innovation tokens — roughly three per project — and every non-boring technology you adopt spends one.
The essay is short. The argument is shorter. Boring technology has known failure modes, documented recovery paths, and a Stack Overflow trail going back years. Novel technology gives you a shiny new capability and a set of unknown unknowns that will surface at 3am on a Saturday. McKinley's proposed test is deceptively simple: for every new tool, write down what problem it solves, what you'd use instead, and what happens when it breaks. Most candidates fail that exercise before you finish the second bullet.
What's notable in 2026 isn't the essay — it's the comment thread. The top replies aren't debating whether Postgres beats MongoDB anymore. They're debating whether a team of four should be running its own vector database, a dedicated inference gateway, an agent orchestration framework, a feature store, and a separate observability stack for LLM traces. All to ship what used to be called "a search box."
The innovation token metaphor has aged in an interesting direction. When McKinley wrote it, the temptation was picking Cassandra when you needed Postgres, or Node when you already had a Rails monolith that worked. The failure mode was a small team pretending to be Google. The 2026 version of the same mistake is a four-person startup running the reference architecture from an AI infrastructure vendor's marketing page.
There's a specific reason this hits harder now: LLMs have collapsed the *authoring* cost of adopting new tech without touching the *operating* cost. Claude or Copilot will happily generate the LangGraph scaffold, the Pinecone client, the Temporal workflow, the OpenTelemetry exporter. The code appears in minutes. The knowledge of what happens when the vector index corrupts, when the workflow engine wedges on a poison-pill task, when the trace exporter starts dropping spans silently — that knowledge takes months to build and lives in exactly one person's head. Guess who's on vacation when it breaks.
Compare two 2026 stacks doing roughly the same thing. Stack A: Postgres with `pgvector`, a background job table, a cron, and structured logs to a single file that gets shipped to CloudWatch. Stack B: a managed vector DB, a workflow engine, a queue, a separate embedding service, and four different observability tools stitched together with YAML. Stack A is *worse* at almost every individual capability. It's also the one where a new engineer can be productive on day three, where you can restore from a backup without reading a runbook, and where nobody has to explain to the board why last month's inference bill was 40% infrastructure overhead.
The HN thread surfaces one uncomfortable pattern that wasn't as visible in 2015: résumé-driven development is now supply-side. Vendors ship reference architectures designed to require their entire product suite. Conference talks are structured around "here's how we solved a problem you don't have with a tool you didn't need." The pressure to pick exciting technology isn't just internal ambition anymore — it's a well-funded marketing function aimed directly at your architecture review meeting.
McKinley's essay implicitly asks a question the industry keeps flinching from: *what if the boring choice is actually the correct one, most of the time, for most teams?* The uncomfortable answer is that it probably is, and that most of the interesting engineering work happens inside the boring tools, not by replacing them. Postgres in 2026 has JSON, full-text search, vector similarity, logical replication, and partitioning that will handle any workload a Series B company will ever generate. The teams shipping fastest aren't the ones running the most impressive infra diagram.
Run the three-question test on your own dependencies this quarter. For each non-obvious piece of infrastructure, write down (1) the specific problem it solves that you couldn't solve otherwise, (2) what the boring alternative would look like, and (3) the last time someone on the team actually operated it under duress. If you can't answer all three, you've found a candidate for consolidation.
Be especially skeptical of anything you adopted in the last eighteen months of AI-tooling hype. Agent frameworks, vector databases, and inference gateways are the current-generation MongoDB — they're not bad tools, but the median team using them would be better off with a `SELECT` statement and a well-placed retry loop. The interesting work is almost always in your prompts, your evaluation harness, and your domain data — not in the orchestration layer.
The corollary matters for hiring too. A candidate who's shipped a small system on Postgres, Redis, and a queue tends to have deeper operational instincts than one who's assembled a large system out of ten managed services. The first person has debugged something at the level where the abstraction leaks. The second has mostly filed support tickets.
McKinley's essay will keep resurfacing because the underlying incentive structure hasn't changed — if anything, LLM-assisted coding has made it easier than ever to *start* using something new and harder than ever to notice the accumulated operational debt. The teams that will look smart in three years are the ones spending their innovation tokens on the actual product, not on the plumbing. Everyone else will be writing postmortems about the workflow engine they picked in Q2 2025 that nobody remembers how to operate.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.