Start from constraints, not preferences
Write down what is actually fixed: the team's existing skills, the hiring market you recruit from, compliance or residency requirements, systems you must integrate with, and your genuine scale.
Most stack debates are conducted as though all options are equally available. Constraints usually eliminate most of them before any technical comparison is needed.
Weigh the team above the technology
A capable team in a merely adequate technology consistently outperforms an inexperienced team in a theoretically superior one. Existing expertise is the single strongest predictor of delivery speed in the first year.
Where you plan to hire, check the market you actually recruit in rather than global popularity figures. A stack that is common globally and scarce locally is a hiring problem you will feel for years.
Spend the novelty budget deliberately
A team can absorb one or two unfamiliar technologies at a time. Spend that where the new technology is genuinely the source of advantage, and take the conventional option everywhere else.
Teams that choose the interesting option in every layer become expert in none of them, while carrying the operational burden of all of them.
Evaluate operations, not just development
Most of a technology's cost is incurred after it is written: upgrades, monitoring, debugging, backups, and the availability of someone who has seen your failure before.
- How long has it been in production use at organisations like yours?
- What does the upgrade path look like, and how often is it breaking?
- Is there a managed hosting option, and what does it cost at your scale?
- When it fails at 3am, how much material exists about that failure?
- Who maintains it, and what happens if they stop?
Prefer reversible choices
Some decisions can be undone at a boundary; others spread through everything. A database accessed through a repository layer can be replaced. A framework whose idioms shape every file cannot.
Where a choice is hard to reverse, that is exactly where to spend longer gathering evidence — including building something small and real before committing.
Write the decision down
Record what was chosen, what was rejected, and which constraints drove it. In two years the constraints will have changed and someone will ask why the stack looks like this.
Without that record the answer is guesswork, and teams either defend a choice whose reasons have expired or discard one that is still correct.