Our default stack is not interesting, and that is a decision rather than an accident. PostgreSQL. A boring web framework. A managed platform for hosting. Tools that have been debugged in public for a decade by people who are not us.
The reasoning is arithmetic. Five people cannot absorb the cost of five unfamiliar technologies at once. Every new tool arrives with a bill: reading its failure modes, learning what its error messages actually mean, discovering the sharp edge that only shows up at 3am under load. With proven tools somebody else has already paid that bill and written the answers down. When something breaks at an awkward hour, the difference between a ten-year-old database and a promising one is whether the fix is a search away or an afternoon of reading source.
The innovation budget
The idea is not ours — it comes from Dan McKinley's "Choose Boring Technology" — but we use it literally. A team gets a small number of tokens to spend on things that are genuinely new to it. Spend them on your database, your deployment pipeline and your language runtime, and you have none left for the product.
The trap is that each of those choices looks reasonable on its own. The new database really is faster for your access pattern. The new runtime really does have better ergonomics. None of them is wrong in isolation, and together they produce a system whose failure surface nobody on the team can hold in their head.
Where we spend it
We spend the budget in one place: the part of the system that is the reason the project exists. If a client is building something around a model, that is where the unproven work goes, and everything underneath it is chosen to be uneventful.
Mostly this is about being able to debug. Novel infrastructure carrying novel product logic is two experiments running at once, and when it breaks you cannot tell which one broke. Keep the foundation dull and a failure becomes immediately informative — it is almost certainly in the part you actually built, which is the part you understand.
It changes what a handover looks like, too. A system built on tools with a decade of public history can be picked up by an engineer who has never seen it, using documentation that already exists. That matters more than it sounds when we hand a system to a client's own team, which is how a good number of our projects are meant to end.
When the boring option loses
This is not conservatism for its own sake, and the rule has an exit. We pick the newer tool when it clears a real bar: when the boring option would cost more over the life of the system than learning the new one would. That happens. It has happened to us, and the resulting choice was correct.
The test we apply is whether we could justify it to whoever maintains the thing in three years, in terms that were already true before the tool became fashionable. If the honest answer is that we wanted to try it, that is a side project, not a client's production system.