The real cost of the wrong stack.

The hidden costs.

The framework you pick on day one is the framework you'll be running in five years. Migrations are theoretically possible, practically rare. So the decision matters more than it feels at the moment you make it.

There are three families of hidden cost. The first is talent: how easy will it be to hire experienced engineers two years from now? The second is operational: how much sleep does this stack cost? The third is dependency: how exposed are you when a critical library author quits maintenance?

Hiring risk.

Pick a popular stack and you have a deep pool of senior engineers to hire from at a fair market rate. Pick a fashionable one and you compete with every well-funded startup for the same 200 people. Pick an exotic one and you become the senior engineer.

We have watched teams choose a beautiful new framework, recruit one rockstar to lead, and then quietly suffer for the next four years when that rockstar moves on and no replacement exists. The framework was correct. The hiring calculus was not.

The operational tax.

Every stack has an operational tax — the engineering hours you spend keeping it alive between feature work. Some are notoriously cheap: a boring Postgres + Linux setup will run for years without ceremony. Some are expensive: anything that requires bespoke clustering, brittle build pipelines, or constant security upgrades to non-LTS dependencies.

We track this in our own work as a percentage of engineer time spent on "maintenance vs ship". Healthy projects sit at 15–20%. Over 35% and the stack is the bug.

Three questions before you choose.

1. If we are still running this in 2030, will the language still have an LTS release? If you can't answer with confidence, pick something else.

2. Can a competent engineer read the codebase in two days and start contributing? Some stacks reward heroes; the good ones reward newcomers.

3. Are you choosing this because it's right for the problem, or because it was in the last conference talk you watched? Boring tech wins more projects than novelty.

Our default stack — and why.

Our default is C# on .NET, ASP.NET Core for web APIs, Postgres for data, Docker on Linux for deployment. We chose this for very specific reasons.

.NET has long-term-support cadence we can plan around. C# is one of the most-hireable languages in our market and the engineers it attracts tend to take production seriously. ASP.NET Core is mature, fast, and unfashionable in exactly the right way.

Postgres is the database we'd choose again every time. Docker on Linux is the boring deployment story that has not failed us yet. None of these will turn up in a Twitter thread next year, which is precisely why we use them.