How to pick a tech stack for a startup, and why boring keeps winning

The stack conversation has a predictable shape. Someone advocates the thing they used most recently, someone else raises performance, a benchmark gets circulated, and the decision lands with whoever was most invested in having it. Six months later nobody remembers the benchmark and the team is dealing with a different problem entirely, which is that the one person who knew the framework has left.

That is the actual failure mode, and it is worth optimising against directly. Two questions decide a stack better than any benchmark: can you hire people who already know it, and will it still be supported when you are too busy to migrate?

The hiring question has published numbers

You do not have to guess at the size of a hiring pool. The Stack Overflow Developer Survey publishes what working developers actually use, and the 2025 results are blunt about the concentration.

Among all respondents, JavaScript is used by 66%, SQL by 58.6%, and Python by 57.9%. On web frameworks, Node.js sits at 48.7% and React at 44.7%, with Next.js at 20.8%. On databases, PostgreSQL leads at 55.6%, ahead of MySQL at 40.5% and SQLite at 37.5%. Those figures come from the 2025 Stack Overflow Developer Survey technology section, drawn from tens of thousands of respondents per question.

Read that as a hiring map rather than a popularity contest. If you build on the things at the top of those lists, a competent replacement is a normal recruitment problem. If you build on something at the bottom, replacing your one specialist is a search, and searches take months you will not have.

Support windows are a cost you sign up for silently

The second question is how long the thing you chose will keep receiving fixes, because that determines when a migration becomes mandatory rather than optional. Runtimes publish this and almost nobody reads it before choosing.

Node.js is a good example because its policy is explicit. A major version spends six months as Current, then even-numbered releases move to Active LTS for 18 months, then Maintenance LTS for a further 12 months, which is 30 months of long term support in total. The policy states plainly that "production applications should only use Active LTS or Maintenance LTS releases". The full schedule and the current LTS versions are on the Node.js releases page.

Thirty months sounds generous until you notice it is the total, not the remaining. Adopt a version late in its Active LTS window and you have inherited a migration inside a year. The cheap habit is to check the remaining support window at the moment you choose, not the headline duration.

The boring default, and where deviating is justified

For most early products the defensible default looks like this, and the interesting part is the right hand column rather than the middle one.

The pattern is that deviation should follow a measurement, not an expectation. A team that adds a queue because the architecture diagram looked incomplete without one has bought operational burden with no corresponding relief. This is the same trap as premature scaling, and it compounds the same way, which is covered from the load side in scaling a web app in the right order.

The three places being interesting is worth it

Boring is a default, not a religion. Three areas justify a deliberate departure.

• The thing your product is actually about. If your value is in a model, a solver or a rendering pipeline, that part earns the best available tool even if nobody else on the team knows it.
• A constraint imposed from outside. Data residency, a client mandated platform, or an integration that only exists in one ecosystem are all reasons, and they are reasons you can write down.
• A cost cliff you have hit. Not one you have projected, one you are currently paying. The distinction matters because projected cliffs almost never arrive on schedule.

Everything outside those three is a preference, and preferences are fine as long as they are labelled honestly rather than dressed as engineering necessity.

What this looks like when you make the first hire

The stack decision and the hiring decision are the same decision, taken months apart, and treating them separately is where the pain comes from.

Before committing, write the job advertisement you would post in a year. If it reads like a normal advertisement that several candidates could answer, the stack is fine. If it reads like a search for a specific person, you have chosen a stack that only works while a particular individual stays, and you should either change the stack or accept that you are hiring a dependency rather than a role.

The same reasoning applies when the build is outsourced, with an extra edge to it, because you are then choosing a stack that someone else has to be able to pick up. The questions worth asking are in how to choose a software development company, and stack ownership belongs on that list.

The honest limits

Three caveats, because this advice is easy to over-apply.

Survey data describes the global developer population, not your city. If you are hiring in a specific market, the local distribution can differ substantially from the global one, and the local numbers are the ones that will decide whether you fill the role. Use the survey as a prior and correct it with what you can observe in your own hiring.

Boring also has a recruiting cost that nobody likes to mention. Some strong engineers are drawn to interesting problems and interesting tools, and a rigorously dull stack is a weaker pitch to that group. It is a real trade, and the right answer depends on whether you are hiring for scarcity or for continuity.

And the stack is rarely the reason a project runs long. It is a visible decision, which makes it a satisfying thing to deliberate over, but the reasons things actually take longer than planned are mostly elsewhere and mostly unglamorous. They are set out in why software projects take so long. A team that spends three weeks choosing a stack has already lost more than any stack choice would have cost them, which is also the argument for settling scope first in scoping a project before anyone writes code.