Why Tech Startups Should Rely on 'Boring' Software Stacks, According to Etsy Engineering Veteran

Software engineering teams at growth-stage technology companies frequently overextend their operational resources by adopting novel software frameworks, according to technical analysis first reported by Hacker News. In a widely circulated architectural manifesto, former Etsy software engineer Dan McKinley argues that tech firms must systematically bias their infrastructure choices toward established, highly predictable software—a discipline he terms choosing 'boring technology.' Drawing from his tenure working under former Etsy engineering executive Kellan Elliott-McCrea, McKinley asserts that managing operational risks matters far more to corporate survival than using cutting-edge tools.

To conceptualize infrastructure risk, McKinley introduces the framework of 'innovation tokens.' Under this model, an organization receives a strictly constrained allowance—roughly three tokens—to spend on non-standard or unproven technologies throughout its early lifespan. Allocating these scarce resources to discretionary tools such as custom database engines, novel runtime environments like Node.js, or nascent service-discovery systems reduces the focus available for a company’s primary business objective. McKinley notes that unless a startup's core product is infrastructure itself, spending finite engineering capacity on non-essential stack innovation delays organizational progress.

The manifesto clarifies that 'boring' technology should not be equated with poorly designed software. Instead, mature tools such as MySQL, PostgreSQL, Python, PHP, Memcached, and Cron qualify as boring because their capabilities and operational boundaries are thoroughly understood across the industry. Crucially, established infrastructure drastically reduces 'unknown unknowns'—unpredictable failure modes that typically surface only when novel software is subjected to real-world production demands. While decades-old systems still present known operational challenges, their failure behaviors are well documented and easier to mitigate.

McKinley challenges the common industry ethos of selecting the absolute 'best tool for the job,' characterizing it as a short-sighted perspective that ignores long-term system costs. Introducing disparate programming languages or database engines—such as pairing Scala and Python or mixing MySQL with Redis—creates severe cumulative overhead. Every additional component introduced to an engineering organization requires dedicated monitoring, unit testing frameworks, deployment scripts, and specialized domain knowledge. Consequently, the long-term expense of maintaining reliable production operations routinely eclipses any initial development time saved by adopting a specialized tool.

To prevent unmanaged technology expansion, the post outlines a formal review process for engineering organizations evaluating new software. Teams are encouraged to first attempt solving technical challenges using existing stack capabilities, forcing developers to articulate exactly why current infrastructure is inadequate. When new technologies are introduced to replace legacy tools, management must mandate strict migration schedules to deprecate old systems. This governance model ensures that technology adoption remains a transparent, company-wide decision rather than an uncoordinated initiative led by individual developers.

As an empirical example of this strategy, McKinley points to the development of Etsy’s activity feeds. Rather than deploying a specialized data store like Redis to power the feature, the engineering team deliberately constrained the implementation to Etsy's existing core platform, which consisted of PHP, MySQL, Memcached, and the Gearman job server. Although building the functionality on the established stack required more upfront complexity, the consolidated infrastructure allowed the activity feeds feature to scale 20-fold over several years without requiring dedicated engineering interventions or custom maintenance.

The essay emphasizes that advocating for mature technology is not an absolute rule, acknowledging that specialized software is sometimes unavoidable when core requirements exceed the capabilities of existing tools. For instance, while Etsy successfully implemented its activity feed within its standard architecture, the company ultimately adopted Apache Solr to handle full-text search and faceted filtering, recognizing that raw PHP could not meet those specific functional demands. McKinley concludes that exercising deliberate restraint in infrastructure selection provides engineers with the operational freedom necessary to address broader business challenges.