**Claim:** Small companies should default to boring, well-established technology (Postgres over a trendier database, Django over a newer framework) unless they have a specific reason — usually a documented constraint — to choose something newer. **Why this matters:** If true, a lot of small companies are paying a hidden tax in operational complexity, hiring difficulty, and outage exposure because they chose the more interesting option. If false, those companies are correctly future-proofing themselves and the boring-tech default is conservatism dressed as wisdom. **The argument's spine:** 1. Well-established technology has accumulated more failure modes and their fixes than newer technology. 2. The marginal benefit of newer technology is usually small for small-company use cases; the marginal cost is meaningful. 3. The decision is asymmetric: if you pick boring and you grow, switching later is cheap relative to switching later if you picked novel and the novel choice didn't work out. **For each sub-claim:** **Sub-claim 1 (more failures and fixes):** - Evidence: empirical patterns from outage post-mortems in public companies. Major Postgres bugs have been known and fixed for years; novel databases regularly surface bugs in production that nobody has seen before. - Weakest evidence: this is a generalization. Plenty of well-established technologies still have ugly edge cases (DNS, certificates), and some newer technologies have unusually mature testing (Rust ecosystem). **Sub-claim 2 (marginal benefit small, marginal cost meaningful):** - Evidence: comparative analyses of operational overhead between mature and newer alternatives in the same category. Hiring data: more engineers know Postgres than know any specific newer database. - Weakest evidence: "marginal benefit small" depends on the use case. A new framework that genuinely fits the problem better is a real benefit, not a marginal one. **Sub-claim 3 (asymmetric switching costs):** - Evidence: case studies of companies that switched off Postgres at scale (they exist, they did fine) versus companies that switched off a novel choice when it failed them (more painful, often unplanned, often during an outage). - Weakest evidence: confirmation bias risk. We hear about the cases where novel choices failed; we don't hear as much about the cases where they worked silently for a decade. **The strongest counterargument:** "Boring technology" was once novel. If everyone defaults to boring, the new boring never gets developed. Companies that adopt newer technology early both shape it (by reporting bugs, pushing patches) and gain real competitive advantages (years of compounding familiarity with what becomes a critical tool). The argument as stated would have told a 2008 startup to use MySQL over Postgres, a 2010 startup to use Ruby over Python, and so on — and in some cases those would have been wrong. **The response:** The counterargument is right that someone has to be an early adopter, and there's value in being that someone. Where it's wrong: most small companies don't have the engineering depth to be early-adopter contributors to a technology's maturation. The cost-benefit math that justifies early adoption is much friendlier at a large company with dedicated infrastructure teams than at a 5-person startup whose competitive advantage isn't in their database choice. The refined claim that survives: small companies should default to boring tech unless they have a specific reason — and "we want to be early adopters of X technology" is a legitimate specific reason, but only if the company has the engineering depth to handle the cost when the bet doesn't pay off. **What the argument doesn't prove:** - Doesn't say what counts as "specific reason." That's case-by-case. - Doesn't say anything about teams of 50+ — the argument is calibrated to small companies and shouldn't be extended. - Doesn't argue against learning new technology; argues against using it in production for load-bearing systems before it's matured. **Calibrated confidence:** Supported but contested. The boring-tech argument has been made well by Dan McKinley and others, and the basic claim has held up in industry experience. But it's not consensus; many smart engineers disagree, and they have legitimate reasons. Frame the piece as "here's the strong version of this case," not "this is settled."