The post is a classic startup engineering essay: spend your scarce novelty budget on the parts of the business that actually differentiate you, and keep the rest of the stack as familiar and proven as possible. In 2015 that meant warning teams away from piling multiple fresh bets on top of each other just because they were fashionable. Reading it in 2026, people mostly felt the advice has aged well, especially after a decade of JavaScript churn, microservice sprawl, and infra choices that created operational drag without creating product advantage.
What landed is not “old good, new bad.” It is that teams routinely underestimate the compounding cost of unknowns. Several commenters reframed the famous “innovation tokens” line as a way to talk about finite organizational attention. If you are doing something hard in the product, do not also invent your database, deployment model, and service topology unless those choices are core to the advantage you are chasing. Familiar tools bring shared operational knowledge, easier hiring, better support, and a much higher chance that neglected systems keep working as load grows. The Etsy example from the essay, where a feature scaled 20x untouched because it sat on the company’s shared stack, was taken as the concrete proof of that logic.
The strongest pushback was aimed less at the strategy than at the slogan. Critics argued that “boring” is too vague to justify anything. Old software can be badly tested, badly documented, or a poor fit for the workload. A tool is only boring relative to the team using it, and even then familiarity does not rescue a bad match between technology and problem. That critique sharpened the conversation rather than overturning the essay. The most useful refinement was that safe technology is not enough. You also need to keep workloads inside the comfort zone of the tool, because teams get into trouble when they reuse familiar systems for jobs they are unsuited to handle.
AI shifted the discussion in a practical way. A lot of people now read “choose boring technology” as “choose in-distribution technology for models and agents.” If LLMs are strongest on widely used stacks with stable conventions and great docs, then using those stacks can multiply engineering throughput. That pulled some commenters toward
Django,
Go,
PHP,
Ruby,
Elixir, and away from sprawling
TypeScript monorepos. Others warned that this can turn into optimizing human systems around model biases, or into overvaluing whatever is common in training data rather than what is actually right for the business. Even there, the center of gravity stayed the same: the point is not nostalgia. It is concentrating complexity where it pays, and refusing to spend precious attention on novelty that does not move the company forward.
mcfunley.com