The Boring Technology Manifesto refers to the principle — articulated by Dan McKinley in his 2015 essay “Choose Boring Technology” — that engineering teams have a finite capacity for novelty, and should therefore spend that capacity on problems that matter (the product) rather than problems that don’t (the infrastructure).
The essay introduced the concept of innovation tokens: each team gets approximately three. A novel database is one token. A novel language is one token. A novel deployment pipeline is one token. Spend all three on infrastructure, and you have no tokens left for the thing you’re actually building.
This sounds obvious. It is obvious. It has been obvious since the first programmer chose a new framework for a CRUD application and spent six months fighting the framework instead of building the application. The Manifesto’s contribution was not the insight — the insight is as old as engineering itself — but the vocabulary, which gave teams a way to say “no” to shiny things without sounding like cowards.
The Innovation Token Economy
The most powerful idea in the Manifesto is the innovation token — a unit of organizational risk capacity that is finite, non-renewable within a project, and almost always spent on the wrong things.
Consider a startup building a food delivery application. The hard problems are: logistics, driver routing, payment processing, and customer trust. The boring solutions are: PostgreSQL, a monolith, server-rendered HTML, and a VPS.
Instead, the startup spends its tokens on: a microservices architecture (token 1), a custom event-sourcing system (token 2), and a Kubernetes deployment pipeline (token 3). The food delivery application is now architecturally indistinguishable from Netflix’s infrastructure, and it has twelve users, all of whom are employees testing the staging environment.
The routing algorithm — the one hard problem that actually required innovation — was never built, because all three tokens were spent before anyone got to it.
“Boring technology is beautiful technology. If you’re fighting the framework, you’re using the framework wrongly.”
— The Caffeinated Squirrel, arriving at this insight after twenty-three episodes of framework fighting, The V3 Saga Final Chapter - Is It Fun To Fight Windmills
The Lifelog Proof
The lifelog itself is the Manifesto made flesh:
- Language: Go — boring, compiles to one binary, no generics drama (until there were generics, and even then, boring generics)
- Database: SQLite — one file, no server, WAL mode, done
- Frontend: HTMX — the server sends HTML, the client says “okay”
- Deployment:
scpa binary,systemctl restart - Architecture: The Monolith — one repo, one binary, Cobra subcommands
Innovation tokens spent on infrastructure: zero. Innovation tokens available for the actual product (a mythology engine built from markdown and SQLite): all of them.
THE BEST INTERFACE IS NO INTERFACE
THE BEST DATABASE IS ONE FILE
THE BEST DEPLOYMENT IS ONE BINARY
— The Lifelog Manifesto, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
Known Pain vs. Unknown Pain
The Manifesto’s deepest insight is not “use old technology.” It is: the failure modes of boring technology are known.
PostgreSQL will run out of connections. You know this. You have a connection pooler. Redis will hit memory limits. You know this. You have eviction policies. A Go binary will use too much memory if you leak goroutines. You know this. You have pprof.
A novel database will fail in novel ways. You do not know these ways. The documentation does not cover them, because the documentation was written by the same three people who wrote the database, and they haven’t encountered the failure mode yet because they have fewer users than you do.
Boring technology lets you focus on your product’s novel failure modes instead of your infrastructure’s novel failure modes. You will have enough failure modes of your own. You do not need to borrow more.
The Squirrel Paradox
The Caffeinated Squirrel is the Manifesto’s most devoted disciple and its most prolific violator. The Squirrel understands boring technology. The Squirrel preaches boring technology. The Squirrel then writes an 827-line manifesto proposing a custom reactive framework with IndexedDB, NATS WebSocket sync, and a blockchain.
This is not hypocrisy. This is the human (or squirrel) condition: knowing the right answer and being constitutionally unable to accept it without first exhausting every wrong answer.
The Manifesto does not prevent this. The Manifesto merely ensures that when the squirrel returns — exhausted, humbled, carrying the wreckage of Copper.js — the boring technology is still there, waiting. PostgreSQL did not leave. Go did not change. HTMX did not add a Virtual DOM. The boring technology was boring the entire time, which is why it still works.
Measured Characteristics
- Innovation tokens per team: ~3
- Tokens typically spent on infrastructure: 3
- Tokens remaining for the actual product: 0
- Age of PostgreSQL: 28 years (still boring, still works)
- Age of SQLite: 25 years (still boring, still works)
- Age of the latest JavaScript framework: 6 months (exciting, status unknown)
- Lines in the Squirrel’s manifesto: 827
- Lines in the HTMX that replaced it: 6
- The boring technology was there the whole time: yes
