The case for a boring stack

How to choose a tech stack: the short answer

Choose the most boring technology that can plausibly do the job, then spend one or two novelty allowances on the component that is genuinely your advantage. The question is not which stack is best in the abstract. It is which stack you can hire for, ship on for three years, and walk away from cheaply when you turn out to be wrong.

Most teams run the decision backwards. They compare frameworks on benchmarks and developer experience, pick the option with the loudest conference talk, then meet the real bill 18 months later in the hiring funnel and the maintenance budget. Build cost is visible and roughly equal across mainstream options. Carrying cost is invisible and varies by an order of magnitude.

A tech stack is the combined set of languages, frameworks, databases and infrastructure tools used to build and run an application, spanning frontend, backend, data and hosting. Each layer is a separate bet with its own exit cost, so decide layer by layer rather than adopting a branded bundle whole.

What is boring technology, and why do senior engineers default to it?

Boring technology is a deliberate policy: default to mature, widely adopted, heavily documented tools for most of a system, and reserve unproven technology for the few components where it creates real competitive advantage. The appeal is not nostalgia. Mature tools have known failure modes, searchable error messages, years of accumulated answers to the exact problem in front of you, and a hiring pool that already understands them.

Usage data shows where the gravity sits. JavaScript remains the most-used language at 66% of developers¹. PostgreSQL leads databases at 55.6% usage¹. Docker rose 17 points in a single year to 71.1%, the largest annual increase of any technology in the survey¹. None of these are surprising answers. They are the answers with the deepest support surface, and support surface is what you are actually buying.

Treat novelty as a budget, not a prohibition. A team that keeps its language, database and deployment layer conventional earns the right to be adventurous in exactly one place: the part of the product competitors cannot copy. Spend the budget on a specialised retrieval engine if search is the product. Spend it on a real-time runtime if latency is the product. Do not spend it on a fashionable frontend framework that only changes how the team feels on a Tuesday.

Novelty should buy a product advantage, not a better developer experience.

Does the tech stack affect how easy it is to hire developers?

It is the largest cost in the decision, and it arrives long before any technical limit does. A stack choice sets the size of your applicant pool on the day you make it. Hiring is already hard on mainstream stacks: 87.5% of technology leaders rate hiring skilled engineers as difficult or worse⁸, and average time-to-hire for engineers moved from 65 days in 2025 to 95 days in 2026⁸. A niche framework multiplies that number rather than adding to it, because the pool shrinks and the compensation premium rises at the same time.

Onboarding compounds it. A mid-level developer typically needs 60 to 90 days to reach full productivity and a senior hire 90 to 120 days⁶, and those windows assume familiar tools. Every unconventional choice adds weeks of ramp-up on top of them. When someone leaves, the bill lands again: replacing a developer is estimated at $200,000 to $300,000 once recruiting, lost knowledge and re-onboarding are counted⁷.

The practical test is local, not global. Search your own hiring market for the framework you are considering, count the engineers who list it, then halve that number for the ones actually available. If the answer is fewer than five people you could realistically reach, you have not chosen a technology. You have chosen a dependency on two or three individuals.

What does the wrong stack cost once you are living in it?

Technical debt is the implied future cost of rework created by taking the fast path now instead of the better one. Stack choice creates it wholesale rather than line by line: an unmaintained framework, a database that does not fit the access pattern, or a runtime nobody on the team can debug produces debt on every feature that follows. Estimates put technical debt at 21% to 40% of an organisation’s IT spending³.

The cost shows up as time before it shows up as a budget line. Developers spend an average of 13.4 hours a week, about a third of their working time, dealing with technical debt⁵. At the enterprise end, the average global business is reported to waste more than $370 million a year through an inability to modernise legacy systems⁴.

Context matters for early-stage teams. Technology startups already carry the highest sector failure rate at 63%², and 92% of SaaS startups fail within three years². Stack choice does not cause those outcomes. It does decide how much of a shrinking runway is spent on maintenance instead of product, and that part is inside a founder’s control.

How does stack choice show up in an exit?

Technical diligence reads a codebase the way a surveyor reads a building. Buyers are not scoring elegance. They are pricing the risk of a rewrite, the cost of absorbing your team, and whether their own engineers can maintain what they are buying. A stack resting on abandoned packages or single-maintainer dependencies converts into a discount or an earn-out condition, because the acquirer has to budget replacement work nobody planned for.

That part of the argument is judgement rather than survey data, and it is worth flagging as such. The reasoning is simple enough to act on: every input a buyer uses to price rewrite risk is set years earlier by the stack decision, so ask at the point of choosing what a technical reviewer would say about each layer in year five.

A better proxy for durability is maintenance evidence, not popularity. Check the release cadence over the last 24 months, the number of distinct people merging code, whether a funded organisation or foundation stands behind the project, and whether the security patch history is current. A framework with one heroic maintainer and a beautiful website is a different asset class from one with a release train and corporate backing.

Technology selection criteria worth weighting

A flat checklist gives every factor equal weight, which is how teams end up optimising for benchmarks. Weight the criteria instead, then score each layer of each candidate against them.

Weighting hiring highest is deliberate, because it is the constraint that binds first. Reversibility takes the second slot because the stack chosen before a first funding round rarely survives to the next one unchanged, which makes the real criterion cheapest to leave rather than best on paper. Standard interfaces, portable data formats and containerised deployment all earn their place on the same logic: they lower the cost of being wrong.

How to choose a tech stack for startups versus enterprise teams

For startups, weight speed and reversibility, and count what the team already knows as a genuine asset rather than a compromise. A team shipping in a familiar stack is months ahead of the same team learning an objectively better one, and months are the currency. The honest exception is when existing knowledge points at something the product cannot survive, in which case pay the learning cost once, early, while the codebase is small enough to move.

For enterprise programmes the weights shift to integration, compliance, vendor support and a ten-year maintenance horizon. The question changes from what ships fastest to what your successor can still operate. That is also where bundle labels stop helping. MERN, MEAN and LAMP are marketing conveniences, not decisions. Unbundle them: choose the database on the access pattern, the backend language on the hiring pool, the frontend on interface complexity, and the deployment layer on your operations capability. The same discipline holds whether the output is a web application or a mobile product, though mobile adds platform lifecycles you do not control.

What to do this week

1. Write the stack down layer by layer, with the reason for each choice in one sentence. Anything you cannot justify in a sentence is a default you inherited, not a decision you made.
2. Run the hiring test on every layer: count reachable engineers in your market, and flag any layer that depends on fewer than five of them.
3. Check maintenance evidence on your three most load-bearing dependencies: release cadence, distinct maintainers, funding, patch currency.
4. Name your novelty budget. Pick the single component where unproven technology earns its risk, and make every other layer conventional.
5. Estimate the migration cost of your riskiest layer in engineer-weeks. If nobody can estimate it, that is itself the finding.

Stack decisions are made once and paid for continuously, which is why they belong early in the software development life cycle rather than in the first sprint. Teams that treat the choice as a hiring and maintenance question, not a taste question, spend less of their engineering capacity servicing decisions they made in a hurry.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.