What is choose boring technology?
Engineering culture and software practice
Choose boring technology is a decision rule from engineer Dan McKinley's 2015 essay, drawn from his years at Etsy. It says: prefer proven, well-understood tools whose failure modes are known over shiny new ones, and spend your limited supply of what he calls innovation tokens on the few things that make your product distinctive. Here boring means well understood, not bad. The aim is to keep scarce attention on work that actually matters.
What this means
Every organisation has a fixed budget for novelty. Learning a brand new database, framework or platform takes real time and attention, and while your people are busy learning it they are not building the thing that makes you money or serves your users. The choose boring technology rule asks you to treat that novelty budget as scarce and to spend it deliberately.
McKinley's memorable framing is that a company gets a small number of innovation tokens. In his essay he suggests roughly three, while stressing the number is approximate and that people tend to overestimate what is in their wallet. Pick a new, unfamiliar technology and you have spent one. Pick another and you have spent two. If most of your tokens are gone on plumbing that nobody sees, you have less capacity left for the parts of your product that are genuinely different and hard.
The word boring is doing careful work here. It does not mean bad or old or unfashionable. It means the tool is well understood: its strengths, its quirks and, crucially, its failure modes are documented, discussed and survivable. A boring tool is one where, when something breaks at an awkward hour, somebody somewhere has already met that failure and written down what to do.
Why it matters
For a small or mid-sized organisation, the cost of an unfamiliar technology is rarely the licence fee. It is the ongoing operational weight: you have to monitor the thing, test it, patch it, learn how to debug it, and find or train people who can keep it alive. McKinley calls this operational baggage, and points out that the long-term cost of keeping a system running reliably almost always dwarfs the inconvenience of building it on plainer tools.
This matters most in build-versus-buy and stack decisions. The instinct to pick the best tool for each individual job sounds responsible, but it quietly multiplies the number of different things your team must understand and support. A smaller set of well-understood tools, each stretched a little further than feels ideal, is usually cheaper to run and easier to hire for than a sprawling collection of locally optimal choices.
The rule has found a sharp second life in decisions about AI tooling. For most small firms, a plain, well-understood workflow beats a novel agent framework that changed shape last month, because the plain approach is documented, debuggable and staffable. There is also a concrete new advantage: because large language models are trained largely on the public internet, established and stable technologies are far better represented in what these models can help you with than brand new frameworks that have few examples in the wild.
None of this is an argument for never adopting anything. It is an argument for spending novelty where it buys you something your competitors cannot easily copy, and for being honest about the running costs everywhere else.
How it works
Where the term came from
Dan McKinley published the essay Choose Boring Technology on his own site on 30 March 2015, and gave a spoken version at the OSCON conference in Portland later that year. He credits much of the thinking to Kellan Elliott-McCrea, his former manager at the online marketplace Etsy, and presents the piece as a distillation of lessons learned there.
The essay's most quoted passage sets out the budget: McKinley suggests that every company gets about three "innovation tokens", that they can be spent however the company likes, and that the supply stays fixed for a long while. McKinley is careful to add that the model is approximate and that teams tend to overestimate how many tokens they really have. He also draws the boring-is-not-bad distinction explicitly, listing then unglamorous but dependable tools as examples of technology that is boring and good.
Known unknowns and unknown unknowns
The heart of the argument is about risk you cannot see. McKinley borrows the language of known unknowns and unknown unknowns. A known unknown is a gap you are aware of, such as not knowing how a database behaves at full load. An unknown unknown is a problem it did not even occur to you to worry about. Every technology carries both, even ones that have existed for decades, but for shiny new technology the pile of unknown unknowns is much larger. His phrasing is that with new tools "the magnitude of unknown unknowns is significantly larger, and this is important." Boring tools have had their surprises found and written up by other people already.
Operational surface area
Adding a technology is not a one-off act; it enlarges the surface you have to operate forever. Each new component needs monitoring, testing, upgrade paths, someone who understands it, and, if it is important, someone reachable when it fails. McKinley's advice is to optimise globally rather than locally: your job is to map business problems onto a small set of tools that collectively occupy the least-worst position, not to pick the theoretically perfect tool for each problem in isolation. The weight of day-to-day operational toil from too many tools, he argues, can crush a team.
How experienced teams spend a token
Because adding technology has company-wide effects, mature teams treat it as a visible, shared decision rather than something an individual quietly does. McKinley recommends a lightweight review: first, write down exactly how you would solve the immediate problem using only what you already have. This flushes out the case where the real reason for the new tool is that someone simply wants to use it, which he says should stop the process immediately. Then write down precisely what about the current stack makes the problem too hard, and if you are replacing something, commit to a migration timeline so you do not just accumulate wreckage. He describes it as a handful of homework questions followed by a meeting, not a daunting bureaucracy.
Examples
Consider a professional services firm of forty people that wants a client portal. The temptation is to build it on the newest framework a contractor is excited about. A boring-technology review asks what the firm already runs and staffs, and concludes that a conventional web stack the in-house developer already knows will ship faster and be supportable after the contractor leaves. The firm saves its novelty budget for the one genuinely distinctive feature: an automated document assembly step that clients will actually notice.
A charity with two technical staff is offered a shiny new workflow platform by an enthusiastic volunteer. Applying the rule, the operations lead asks who will monitor, patch and debug it at two in the morning if it fails during a fundraising campaign. The honest answer is nobody. They instead extend a boring tool they already understand, accepting that it is slightly less elegant, because supportability outranks elegance for a team that thin.
An eight-person software team is choosing how to add AI features. One engineer proposes a fast-moving agent framework that has changed shape twice this year. The team runs the lightweight review and notes that a plain, well-documented approach is not only safer to support but also better represented in the models they will lean on for help. They spend their innovation token on the part of the product that is actually novel, and keep everything around it boring.
Common misunderstandings
Boring means bad or outdated. It does not. McKinley is explicit that boring means well understood, with known capabilities and, more importantly, known failure modes. There is technology that is both boring and bad, and you should avoid that; the target is boring and good enough.
The rule means never adopt anything new. It does not. Taken to an absurd extreme it would mean building everything in one language and nothing else, which McKinley calls crazy. The point is to spend novelty deliberately and rarely, on the things that differentiate you, not to freeze.
The three tokens are a hard limit. They are not. McKinley calls the number approximate and says the model is only a rough aid to thinking. The real message is that novelty capacity is scarce and easy to overestimate, not that exactly three is a rule.
This is the same idea as resume-driven development. It is not. Resume-driven development is about the motive of an individual engineer choosing tools to burnish their CV, and the existing Resume-driven development article covers that behaviour. Choose boring technology is the positive decision rule and the shared token budget an organisation adopts, rather than a diagnosis of why one person pushed for a fashionable tool.
Boring technology has no downside. It can, if applied thoughtlessly, become an excuse to let a stack calcify, to ignore bit rot, or to be so late to a genuinely better approach that you pay for it. Boring is a strong default, not a prohibition on ever changing your mind.
Risks and boundaries
The main risk is dogmatism. A leader who repeats choose boring technology as a slogan can suppress every worthwhile change, including the ones that would repay a token many times over. Boring can shade into stagnation: dependencies age, security patches stop coming, and the tool that was sensible in 2018 becomes a liability. The rule assumes you will still spend tokens, just carefully, and it says nothing about neglecting maintenance of the boring things you already run.
There is also a judgement gap the essay does not fully close. Deciding what is boring enough is genuinely hard at the edges, and reasonable engineers disagree about whether a five-year-old tool has crossed from risky to proven. The token count itself is a metaphor, not a measurement, and treating it as precise is a misreading. Finally, the rule is aimed at ordinary product organisations; a database company or a research lab may quite properly spend most of its tokens on the very thing everyone else should treat as boring. The debate that remains live is where the boundary sits for AI tooling, which is both genuinely new and moving fast, and where being too boring for too long carries its own cost.
What to do next
Name your novelty budget out loud. Agree with your technical people that adopting an unfamiliar technology is a shared, visible decision, not something that happens quietly, and that you will only spend that budget on things that genuinely differentiate what you do.
Adopt a lightweight new-technology review. Before saying yes, ask two questions in writing: how would we solve this with what we already run, and what specifically about the current setup makes that too hard. If the honest answer to the second is thin, stop.
Count the running costs, not just the purchase. For any proposed tool, ask who will monitor it, patch it, and be reachable when it fails, and whether you can hire or train for it. If nobody owns those answers, the tool is not free.
Apply the same test to AI choices. For most workflows, favour a plain, well-understood approach over a fast-changing framework, and reserve novelty for the one place it buys you something rivals cannot copy.
Revisit your boring choices on a schedule. Being boring is not permission to neglect upgrades and security; set a regular check so that proven does not quietly become unsupported.
FAQs
Who came up with choose boring technology?
Engineer Dan McKinley, in an essay published on his own site on 30 March 2015 and later given as a conference talk. He credits lessons learned working under Kellan Elliott-McCrea at the marketplace Etsy.
What is an innovation token?
A metaphor for a unit of your organisation's scarce capacity to adopt something unfamiliar. McKinley suggests a company has roughly three, while stressing the figure is approximate and that teams overestimate how many they hold.
Does boring mean old or bad?
No. Boring means well understood, with known capabilities and known failure modes. McKinley warns that some technology is both boring and bad, and that you should choose things that are boring and good enough.
How does this apply to AI tools?
For most small firms a plain, documented workflow beats a novel framework, because it is easier to support and staff. Established technologies are also far better represented in the data that AI assistants draw on.
Is this just resistance to change?
No. It is deliberate spending of a limited novelty budget on the things that differentiate you, and a strong default towards the proven everywhere else. It still expects you to adopt new things, carefully.
How do I run a new-technology review without slowing everything down?
McKinley describes it as a few homework questions and a short meeting: how would we do this with current tools, and what exactly makes that too hard. It is meant to be quick, not a committee.
What is the biggest risk of following this rule?
Turning it into dogma. Refusing every change lets your stack calcify, dependencies age and security patches lapse. Boring is a strong default, not a ban on ever changing your mind.