Boring infrastructure is a feature

Nobody has ever crossed a bridge and thought, "I wish this were more innovative." The highest compliment infrastructure can earn is that you forgot it was there.

I'm not an engineer. I've spent years working next to the people who build and run payments infrastructure, close enough to watch how technology choices get made and what they cost later. From that seat, one pattern is consistent enough to write down: payment systems get into trouble when someone decides the codebase needs to be exciting.

How excitement gets into the system

It never arrives labeled as risk. It arrives as a perfectly reasonable argument: this new datastore handles our write pattern better; this new framework eliminates a class of bugs; this rewrite will finally pay down the debt. Each argument is locally correct. The aggregate result is a system whose failure modes nobody has lived with for ten years.

Dan McKinley's "Choose Boring Technology" gave engineering the vocabulary: innovation tokens, spend them sparingly. What I'd add from the payments side: the budget shrinks with the cost of your failures. A social app that loses an hour of posts has an incident. A payments switch that loses an hour of transactions has a small museum of human consequences: missed train tickets, double-charged groceries, a merchant's settlement that didn't arrive before payroll.

When your failures are denominated in other people's money, you get maybe one innovation token. Spend it where it actually buys something.

Where the token went

On Hyperswitch, the team spent its token on Rust. That sounds like the opposite of boring: a newer language, a smaller hiring pool, longer onboarding. But watching the decision play out, the accounting made sense, because what Rust bought was boringness at runtime: a payments switch where a whole genus of memory bugs can't reach production. The team paid with ramp-up time, which is visible and budgetable, instead of paying with 3am incidents, which are neither.

Everything else stayed deliberately dull: databases every failure mode of which is documented in a decade of someone else's postmortems, deployment as containers and not much else. Visitors to the codebase sometimes seem mildly disappointed, which I've come to read as praise.

Boring is a moral position

Here's the part I believe that's harder to defend in a meeting: for financial infrastructure, boringness is not just an engineering preference. It's a stance about who bears risk.

Exciting technology distributes its risk downward. The team that chose it gets the conference talk; the merchant whose Friday settlement failed gets the consequences. Boring technology keeps the risk where it belongs, with the people who have the context and the pager.

The businesses I care most about, small ones with thin margins and no engineering team, can't evaluate your stack. They extend you the same trust my family's customers extended a shopkeeper: the assumption that the system behind the counter simply works. Boring infrastructure is how you deserve it.