Choosing a tech stack for a new web application in 2026

Every few months a new framework arrives with a compelling benchmark and a community that insists everything before it was a mistake. Most of them are genuinely good. Almost none of them are the right choice for the project in front of you.

Technology choices should be driven by constraints, not enthusiasm. Here is how we approach them.

Start with the team, not the technology

The best technology for a project is the technology the team maintaining it knows well. A React application maintained by a team that knows React will outperform a theoretically superior framework maintained by a team learning it under production pressure.

This sounds obvious. It is routinely ignored.

The questions that matter

Who will maintain this in two years?

If the answer is “we do not know yet”, choose the most widely adopted option in the relevant category. Hiring for React is easier than hiring for a framework with 3,000 GitHub stars.

What are the scaling constraints?

A marketing site and a real-time trading platform have different requirements. The marketing site does not need WebSockets. The trading platform does not need a static site generator. Matching the technology to the actual scaling requirement prevents both over-engineering and under-engineering.

What does the data layer look like?

The choice of database and ORM has more long-term impact than the choice of frontend framework. Relational or document? Managed or self-hosted? These decisions are harder to reverse than switching from one React meta-framework to another.

What is the deployment target?

Vercel, AWS, a client’s on-premise server, a containerised environment — the deployment target constrains the technology choices. A framework that requires a specific runtime may not be deployable where you need it.

Our current defaults

These are not universal recommendations. They are the choices we reach for when the constraints do not point elsewhere.

• Frontend: Next.js for applications that need SSR or SSG; React with Vite for SPAs where the backend is separate.
• Backend: Node.js with TypeScript for most API work; Python for data-heavy or ML-adjacent services.
• Database: PostgreSQL as the default relational database; MongoDB when the data model genuinely suits a document store.
• Infrastructure: AWS for most production workloads; Vercel or Cloudflare for frontend-heavy projects where the managed platform is worth the cost.

The framework that launched last month

New frameworks are worth watching and occasionally worth using. They are rarely worth using on a production application that needs to be maintained by a team that does not yet know them.

The cost of learning a new framework is paid in production incidents, slower development and harder hiring. That cost is sometimes worth it. It should always be calculated explicitly, not absorbed silently because the benchmark numbers were impressive.

Choose boring technology for the parts of the stack that need to be reliable. Save the interesting choices for the parts where the interesting choice genuinely solves a problem you have.