You are choosing a hiring pool
Every stack decision sets how many people can maintain the system, how long a replacement takes to find, and how quickly a new starter becomes useful. Those costs arrive years later, which is why they are systematically underweighted at the moment of choosing.
Novelty is a real cost, not a taste question
A technology with a small community means fewer answers when you are stuck, fewer libraries, and a longer search when someone leaves. It can still be right — but it should be chosen knowing the premium, not by assuming there isn’t one.
The stack question isn’t “what is best?” It’s “who will still be here to run this?”
Boring in the core, interesting at the edges
A conventional core with novelty confined to the one place it genuinely earns its keep gives you most of the benefit and little of the risk. Keeping that novelty behind an interface is what makes it replaceable, the same reasoning as keeping a model swappable.
Count what you already run
A second language, a second database, or a second deployment model doubles a category of operational knowledge. Adding one should clear a higher bar than adding a library, because the cost lands on everyone permanently.
Ask who maintains it in two years
This is the same question that decides build versus buy, and it deserves an answer with a name attached. If nobody can give one, prefer the option with the largest pool of people who could.
Write the decision down
A short record of what was chosen, what was rejected, and why prevents the same argument recurring annually and gives whoever inherits it the context to know when the reasoning has expired. That is also what keeps a future rewrite argument honest.