Choosing boring technology

There is a moment at the start of every project when the stack auditions for you — the new framework with the beautiful benchmark, the database that promises to make a hard thing disappear. We usually cast the boring one, and we do it on purpose.

Novelty is a budget

A small team can absorb only so much unproven technology before the product itself becomes the experiment. Every novel tool arrives with undocumented failure modes, unanswered questions, and a community too young to have hit your problem yet. Spend that budget on the stack and there is nothing left for the thing you are actually making. We would rather our products be the interesting part.

Boring does not mean old or unloved. It means the failure modes are known, the answers are searchable, and a decade of other people's incidents has already been converted into documentation. When boring technology breaks, someone has usually written down exactly how.

What boring looks like here

• Static pages before servers. This site is prerendered files. There is no fleet to scale, no cache to invalidate at midnight, and very little that can go down.
• A database that is a single file. Our content tooling runs on SQLite, on our own machines. It is one file we can copy, inspect, and back up like any other.
• Dependencies we could carry. Before adopting a library we ask whether we could maintain it ourselves if it were abandoned tomorrow. A no is allowed to veto.

Boring technology is a way of buying certainty with someone else's decade of bug reports.

The cost is a kind of professional restraint. There are tools we would genuinely enjoy that we decline, and from the outside the stack can look unambitious. But software meant to run for years should stand on ground that has already stopped moving — and the ambition belongs in what we build, never in what we build it with.