How to choose a tech stack in 2026: our checklist

Choosing the tech stack for a new project is the single most important long-term commitment you make before writing a line of code. It will stay with you for 5-15 years. You will hold it responsible for half of your future problems (often unfairly), and for half of your successes (also unfairly). Yet most stack decisions are made by inertia, by trend or by whoever speaks the loudest in the team. Let’s look at a concrete checklist for making this choice deliberately in 2026.

TL;DR

• Seven evaluation criteria: talent pool, ecosystem maturity, longevity, operability, lock-in, AI tooling, fit with the domain.
• The Italian talent pool matters more than it seems: hiring a Rust developer in Italy in 2026 costs 30-40% more than a Node.js one for comparable fit.
• AI evolution is the new strategic factor: stacks with good LLM support for coding assistance (Python, TypeScript, Go) accelerate development by 20-40% compared to niche stacks (Rust, Elixir, Clojure).
• The “hype technology” trap is everywhere: every year there are 2-3 “future” frameworks that are stagnant after 24 months. Resisting the new shiny is a technical leadership skill.
• The stack we use (TypeScript + Node.js + Postgres + Astro/React + Python only for ML): choices made deliberately to optimize the 7 criteria above. It’s not “the best”; it’s what optimizes our context.

Why stack selection matters in 2026 (more than in other years)

Three dynamics from 2025-2026 have made stack selection more delicate than in the past:

First, AI coding assistance has changed productivity. Developers with Cursor, Claude Code, GitHub Copilot, Cline produce 30-50% more tested and working code on well-supported stacks (TypeScript, Python, Go) compared to niche stacks. The stack is no longer just “let’s make developers comfortable”: it’s “let’s give them access to the best AI tooling out there”. Stacks with low volume of public open-source code (Elixir, Crystal, Nim) produce less useful AI assistance.

Second, the Italian talent pool has changed. Over the last 5 years it has polarized: the number of TypeScript, Python, Go, Rust devs is growing; the number of Ruby, Scala, “pure” PHP devs is dropping. Stacks that 5 years ago had a wide pool (Ruby) today have talent scarcity in Italy. Choosing them today is betting on future availability.

Third, cloud cost pressure has revalued efficiency. Interpreted stacks with high overhead (pure Python, Ruby, some Node configurations) cost more infrastructure at medium-high scale compared to Go, Rust, modern Java. Above a certain traffic threshold, the stack becomes a non-trivial operational cost line.

The 7 criteria of the checklist

Seven questions in decreasing order of importance for the Italian 2026 context. Each criterion should receive a score (1-5) and the weighted scores give an overall evaluation.

1. Italian talent pool

How many competent developers on this stack are there in Italy? How much does it cost to hire them? How quickly can we replace one who leaves?

Wide pool (>= 5,000 active devs in Italy): TypeScript/JavaScript, Python, Java, PHP, C#/.NET, SQL (across all major DBs).

Medium pool (1,000-5,000 devs): Go, Kotlin, Swift, Rust, Vue.js, Ruby.

Narrow pool (under 1,000 devs): Elixir, Clojure, Haskell, Scala, F#, OCaml.

Concrete test: open LinkedIn Italy, search for “Go developer”. Compare with “Python developer”. The difference in results (and in salary expectations) is your talent pool premium. For 3-7 year projects, overestimating talent availability is a common mistake.

2. Ecosystem maturity

How many ready-to-use libraries exist for the problems you’ll have to solve? Maturity is measured concretely: look at the 10-15 libraries you’ll surely use (authentication, ORM, web framework, queue, monitoring, etc.) and evaluate whether they are mature, maintained, documented.

Excellent: Python, TypeScript/Node, Java, C#. Decades-old ecosystem with near-total coverage.

Good: Go (grown a lot), Rust (grown but some niches still weak), Ruby (historical, now in decline).

Limited: younger languages (Zig, Crystal, Gleam), which have technically excellent cores but ecosystems still to be built.

An immature ecosystem means writing yourself what in other stacks is a single npm install. It costs.

3. Longevity (will it still be alive in the next 10 years?)

Frameworks and languages follow lifecycles. The probability that your stack will still be relevant in 2036 is a strategic factor.

High longevity: mature languages with large installed base (Java, Python, JavaScript, C#, Go, SQL). Probability >85% they will still be primary in 2036.

Medium longevity: languages with strong backing and growing adoption (Rust, Kotlin, Swift). Probability 70-85%.

Uncertain longevity: niche or very new languages/frameworks (Bun runtime, Deno, young frameworks like Astro itself). Probability 40-70%.

Low longevity: hype-driven frameworks with boom + bust (CoffeeScript, AngularJS, various generations of “the next big thing”). Probability under 40%.

The operational principle: the core of your stack (language, primary DB) must be high longevity. The peripheries (UI frameworks, single libraries) can be medium longevity. Building everything on low-longevity components is betting on a single horse.

4. Operability (how easy is it to manage in production?)

The stack generates operational overhead: monitoring, deployment, debugging, scaling. Different stacks have different profiles.

Excellent operability: Go (static binaries, simple deploy, fast runtime), Java (mature tooling, very deep observability), TypeScript/Node (simple to deploy, rich ecosystem).

Medium operability: Python (GIL, occasional dependency hell, slow cold starts), Ruby (memory consumption, GC), C#/.NET (excellent on Windows/Azure, moderately OK elsewhere).

Complex operability: Rust (long compilation, toolchain learning curve), C++ (memory management, build systems), Elixir/Erlang (BEAM mental model, different debugging).

What to measure: build times, size of deployed artifacts, runtime complexity, quality of observability tools (APM, distributed tracing, profiling).

5. Lock-in (how easily can you change in the future?)

Technology lock-in = ability to abandon the stack without rewriting everything.

Low lock-in: standard languages with multiple implementations, open-source frameworks with good portability. Example: TypeScript code with a portable web framework (Express, Fastify) can migrate to another framework at limited cost.

Medium lock-in: opinionated but open-source frameworks. Example: Rails, Django, Laravel - migrating away is a significant rewrite but feasible.

High lock-in: proprietary platforms. Example: closed vendor-specific technologies, proprietary low-code platforms, function-as-a-service with non-standard runtimes.

For long-term projects, reducing lock-in is strategic even if no one is thinking about changing today. Companies that chose Heroku 10 years ago are now discovering what lock-in means when prices change.

6. AI tooling compatibility (new criterion)

In 2026, the quality of AI development assistants for your stack is a real productivity factor.

Excellent AI support: Python, TypeScript/JavaScript, Go, Java, C#. Huge volumes of public code, LLMs trained on these, superior autocomplete and generation.

Good: Rust, Swift, Kotlin, PHP. Growing volumes, AI quality improving.

Mediocre: Ruby (volume declining), Scala, R, Elixir.

Limited: Haskell, Clojure, Erlang, niche languages.

The practical impact: on Python a developer with Claude Code or Cursor produces 30-50% more useful code. On Haskell, the increase is 5-15%. It’s not marginal.

7. Fit with the domain

Some domains have natural technical fit with specific stacks. Ignoring it is inefficient.

ML/data science: Python is dominant for ecosystem reasons (PyTorch, scikit-learn, pandas). Other choices require expensive bridges.

Low-latency systems at high scale: Go, Rust, modern Java. Python and Ruby pay the overhead.

Native mobile development: Swift (iOS), Kotlin (Android). Cross-platform: React Native or Flutter.

Enterprise integration systems: Java, C#/.NET have the advantage of decades of existing integrations.

Modern full-stack web: end-to-end TypeScript (Node + React/Vue/Svelte + Postgres) is today almost always the optimal choice for medium-scale modern web projects.

The “hype technology” trap

Every 18-24 months a framework is born that “changes everything”. In the last 5 years: Deno (2020), Bun (2022), HTMX (2023), Astro (2023), Tauri (2023), Hono (2024), many others. Some stabilize (Astro is now mainstream). Others remain interesting experiments without enterprise adoption (HTMX, Tauri).

The problem: whoever picks the hype framework in the peak hype phase pays a hidden cost if it doesn’t stabilize. Limited ecosystem, missing libraries, scarce talent, partial AI tooling.

The operating rule: for the core of your stack (language, DB, runtime), wait at least 24-36 months from the moment the framework becomes popular before adopting it. If at 36 months it’s still relevant (see Astro, Next.js), it can be adopted with less risk. For peripheral concerns (a UI component, a build tool) the risk is lower: you can experiment.

Concrete case: Bun runtime in 2024 was hype. In 2026 it has matured and has real adoption, but the Italian talent pool is still 10x below standard Node.js. Adopting it for an enterprise project means betting that in 5 years the pool will have grown. Maybe yes, maybe no.

The stack we use (and why)

For transparency, the stack we currently adopt as default at Obsidian Technologies for new projects:

• Primary language: TypeScript end-to-end (frontend + backend). Maximum talent pool, excellent AI tooling, high longevity, low lock-in.
• Backend runtime: Node.js (recent LTS). Bun as an alternative for specific projects where performance matters. We remain cautious on Deno.
• Primary database: PostgreSQL. Decade-long maturity, universal talent pool, superior ecosystem, excellent operability.
• Cache/queue: Redis. Industry standard, great operability.
• Frontend framework: Astro for content-heavy sites (this blog is in Astro), React/Next.js for complex applications. Vue for projects with teams that know it better. No new Angular, legacy Angular gets maintained.
• Mobile: React Native when cross-platform is needed. Native (Swift/Kotlin) when the product is mobile-only and deserves a dedicated team.
• Python: only for ML, data science, Python-specific integrations. Not for standard web backend.
• Cloud: Vercel for frontend-heavy projects, Fly.io for custom backends, AWS/Azure/GCP for enterprise scenarios.
• AI tooling: Claude Code + Cursor as standard coding assistants. GPT API or Claude API for applications that need LLMs.

The choices we do NOT make (and why):

• Rust for web backend: excellent for low-latency systems, but for most Italian enterprise projects the talent pool is too narrow and development times stretch by 30-50%.
• Modern Java: not wrong, but for new projects the development cost is higher than TypeScript. We use it only where there is existing Java infrastructure to preserve.
• PHP: not dead, but the qualified Italian talent pool has moved elsewhere. We maintain it only on legacy projects.
• Microservices as default: high operational complexity. Adoptable only above certain scale and team size thresholds. For 90% of our solutions a modular monolith is the right choice.

This is not “the perfect stack”. It’s the stack that optimizes our specific context (services to Italian SMEs, small-to-medium team, time-to-market matters). Your context may require different choices.

Common mistakes in stack selection

1. Letting the most vocal developer decide. The dev who speaks loudest in the team often has personal biases (“I want to learn Rust”, “Vue is better than React because I know it”). The strategic choice should be made by technical leadership with input from the team, not outsourced to the most convinced one.

2. Choosing by conference-driven development. Adopting a stack because “everyone talks about it at the conference” or “Netflix uses it” without evaluating whether your context resembles that of the reference user. Netflix uses Java and Python at a different scale than yours; what works for them doesn’t necessarily work for you.

3. Not considering the medium-term talent pool. The stack gets chosen for the current team. But the team changes: after 5 years the original core team is often no longer there. If the stack is exotic, replacing becomes a problem.

4. Underestimating AI tooling. In 2026 whoever picks a stack with low AI support accepts a productivity gap of 25-40% over the next 5 years. It’s a cost that capitalizes into salaries, time-to-market, code quality.

5. Changing stack mid-project. The temptation to “let’s drop what we started, restart with X which is better” is almost always wrong if the project is over 30%. The switch cost exceeds the benefit. Companies that do this often repeat the same mistake with a third stack 2 years later.

6. Custom architecture without need. Building microservices, event-driven, CQRS, hexagonal architecture from scratch for projects that don’t require it is the single largest generator of over-engineering in 2026. Always start from a well-written modular monolith.

FAQ

How do you evaluate the stack of an existing project to decide whether to keep it or change it?

Five questions: (1) is the talent pool declining (e.g. PHP)? (2) is longevity at risk (e.g. deprecated framework)? (3) is AI tooling scarce? (4) are operational costs growing? (5) has the fit with the domain changed (e.g. have you become more AI-heavy)? If yes to 2+ questions, consider gradual migration. If 1 yes, consider upgrading within the stack instead of switching.

Is it worth doing cross-stack projects (backend in a different language than frontend)?

At Obsidian we prefer mono-language where possible (fullstack TypeScript) to reduce context switching, share types, simplify hiring. Cross-stack (e.g. Python backend + TypeScript frontend) makes sense when the domain imposes Python (ML), or when the internal team is split by skill and this is efficient. Not as a default choice.

Open-source vs proprietary stack: practical difference?

Open-source is almost always preferable to reduce lock-in. Exception: proprietary technologies that are de facto standard (AWS RDS, Vercel, etc.), where the vendor lock-in is accepted in exchange for reduced operations. Never choose proprietary for the core business logic.

How much does the availability of Italian open-source libraries weigh?

Practically zero as a selection factor. Global open-source libraries (npm, pip, crates.io) are what matters. Italian production is marginal everywhere.

How do you handle the fear of missing out on new frameworks?

Have an innovation budget of 10-15% of team time dedicated to exploring new technologies without committing. Devs can experiment with Bun, HTMX, Tauri, etc. in internal side projects. If something matures in the next 2-3 years and becomes adoptable, the team already has experience. If it doesn’t mature, you haven’t invested in production.

Is the ThoughtWorks/Gartner technology radar useful?

Yes as input, no as oracle. They publish useful evaluations on technology maturity. They are biased toward enterprise consulting (they prefer technologies that sell well), and partially toward the US market. Use them as one voice, not as the voice.

Conclusion

Choosing the tech stack in 2026 requires deliberateness more than ever. The old criteria (language comfortable for the team, framework I like) are insufficient: the talent pool, AI tooling, longevity, operability are strategic factors that must be evaluated explicitly. Companies that do this build products that age well for 8-15 years. Those that don’t find themselves chasing rewrites every 4-5 years.

If you’re about to start a new project and want an independent stack evaluation for your case, let’s talk. We can run a stack assessment session of 4-8 hours that saves you years of regret.

To go deeper: the pillar page security-aware custom software, and the related article custom software vs SaaS for those deciding whether to build or buy.