The relevant timescale is longer than the excitement
Hospital software is bought slowly, deployed slowly and kept for a long time. A choice made this year will be operated by people who have not been hired yet, on infrastructure that has not been specified yet.
That timescale changes the calculation. A technology that is delightful now and unmaintained in four years has not saved anybody time; it has borrowed it at an unfavourable rate.
What 'boring' actually means
Not old, and not unfashionable. Boring means the failure modes are documented, the operational characteristics are known, and when something goes wrong at an awkward hour the answer is findable by someone who was not part of the original decision.
A mature database is boring. A widely used language runtime is boring. Both are still being actively improved; what makes them boring is that their surprises have mostly already been had, in public, by somebody else.
The questions that settle it
If the person who introduced this leaves, can somebody else operate it? If the answer requires that person to be reachable, the tool has become a dependency on an individual.
What happens when it fails at three in the morning? Not whether it fails everything fails but whether the failure is legible to whoever is looking at it.
How do we get out? An adoption with no exit is a permanent commitment made on partial information. We do not require a full migration plan, but we do require that somebody has thought about it for ten minutes and not been alarmed.
And: what does this replace? Adding a tool without retiring anything is how a stack becomes an accumulation.
Spend the novelty budget deliberately
A team can carry a small number of genuinely new things at once before its ability to reason about the whole degrades. That capacity is finite and worth spending on purpose.
So the question is never just 'is this good'. It is 'is this the thing we want to be learning right now, at the cost of not learning something else'. Usually the honest answer is that the novelty is better spent on the domain than on the infrastructure.
Where we do reach for something new
When the boring option cannot do the job, and we have established that rather than assumed it. There is a real failure mode in the other direction: teams that avoid every new thing accumulate workarounds that are individually reasonable and collectively a bespoke framework nobody chose.
The tell is when the workarounds start needing explanation to new people. At that point the conservative choice has become the expensive one.
This is not an argument against craft
Choosing familiar components does not mean building carelessly. The interesting work in this domain is almost never the framework it is the model of a patient journey, the correctness of a consent rule, the behaviour of a screen at the end of a long shift.
Those problems are genuinely hard, and they are hard in ways no amount of infrastructure novelty helps with. A team that has spent its attention on the substrate arrives at them tired.
Keeping the substrate unremarkable is what leaves room for that to be done well. It is a boring choice made in service of an interesting one, which is usually the shape of a good technical decision.
If any of the above matches a problem you are dealing with, we are happy to go deeper than a blog post reasonably can.