Pick any week and there's a new framework, a new edge runtime, a new state library that's going to change everything. Almost none of them do. The web development stack that actually ships products in 2026 is narrower, more boring, and more capable than the discourse around it suggests. Here's what we'd pick for a new web app today, why, and the noise to ignore.
The default: Next.js + React + TypeScript
If you're building a modern web app and you don't have a strong reason to pick something else, the answer is Next.js (App Router) with React and TypeScript. This isn't because it's trendy. It's because the combination handles the three things every serious web app needs — server rendering, routing, and a strong type system — without any glue code, and because the ecosystem around it is enormous and mature.
What used to be separate decisions ("front end framework, back end framework, build tool, routing, data fetching") is now one decision. Server Components fetch your data on the server with full type safety. The same file describes the page, its layout, and its SEO metadata. The result is fewer moving parts, less code, and far less of the configuration tax that used to define "modern web."
That said: Next is a default, not a religion. If your product is a docs site, Astro might be better. If it's a heavy interactive editor, plain Vite + React is fine. The point is to pick deliberately, not by trend.
TypeScript is not optional
A 2026 web codebase without TypeScript is a self-imposed handicap. The cost is a few extra characters per file; the benefit is that whole classes of bugs become impossible, refactors become safe, and your IDE turns into a second pair of eyes. Strict mode on, no any, no exceptions. Teams that resist this usually argue it slows them down — and usually mean it slows them down for the first week, after which it makes them measurably faster.
State, fetching, and the boring stack that wins
The state-management debate is mostly over. For most apps:
- Server data lives on the server (Server Components, React Server Functions, or a thin data layer). Stop shipping the same JSON to two places.
- Client cache uses TanStack Query (formerly React Query) or a built-in equivalent — never roll your own.
- UI state uses React's built-ins (
useState,useReducer, Context). Reach for Zustand or Jotai only if a real bottleneck pushes you there. - Forms use React Hook Form + Zod — typed, validated, and small.
If you find yourself arguing about Redux in 2026, that's a smell. The ecosystem has converged on simpler, more local solutions.
Styling: Tailwind, with components for repetition
Tailwind has quietly become the default styling layer for serious React work. Not because it's beautiful but because it's pragmatic: utility classes co-located with the markup, no class-name fights between teammates, and predictable output. The pattern that works long-term is utilities for the 80% case and a small set of named components for buttons, inputs, badges, and other things you repeat.
CSS-in-JS libraries that were the answer five years ago (Emotion, styled-components, etc.) have largely faded out of new builds because they don't play nicely with Server Components and add runtime cost for little benefit.
Databases and the back end
For the back end of most web apps, the boring answer is the right one: Postgres (managed — Supabase, Neon, AWS RDS), accessed via a typed query layer like Drizzle or Prisma. Don't reach for NoSQL unless you have a real reason — Postgres handles JSON, full-text search, and even pretty good vector search now, so a single database covers more ground than it used to.
For APIs, Server Actions and Route Handlers in Next.js mean a lot of teams genuinely don't need a separate API layer for their own product. Build one when you need it (mobile clients, third-party access), not before.
Hosting: Vercel, or AWS — pick deliberately
The deployment decision splits cleanly:
- Vercel if you want the fastest path from
git pushto a globally-cached app. Best-in-class Next.js integration, near-zero ops. - AWS / Cloudflare if you have stricter cost, compliance, or infrastructure needs, or you're building enterprise software where the deployment shape is dictated for you. We do plenty of AWS-based web work — both routes are fine; the wrong move is hand-wringing about it for weeks.
The "edge vs serverless vs container" debate is largely overblown for products with under, say, 100k users. Use what your hosting provider makes easy.
AI: assume it's part of the stack now
Most non-trivial web apps in 2026 have at least one AI feature — search, summarisation, drafting, classification. That doesn't mean spinning up an ML team; it means treating hosted LLMs as a normal dependency you call from your app, with RAG for grounding and proper guardrails. (We wrote a whole post on adding AI without hiring an AI team if that's where you are.)
What to ignore
A few things that get a lot of attention but rarely justify it in a real build:
- Micro-frontends for products with one team and one product. The complexity tax never pays back.
- Brand-new frameworks without a real ecosystem. The bug you hit at 11pm has to be findable on the internet.
- Premature edge / streaming SSR optimisation before you have a measurable problem.
- Switching frameworks to fix what is, on inspection, a code quality problem.
What actually matters
Pick a default stack, stop revisiting that decision, and put the saved energy into the things that actually decide whether your web app succeeds: page speed and Core Web Vitals (which still dominate SEO), accessibility (which still gets shipped after the deadline), instrumentation (so you can see what's slow), and a deployment story so smooth your team ships every day instead of every fortnight.
This is the stack we use to ship our own web apps — including Lexa — and the one we recommend to nine out of ten clients who ask "what should we build with?" If you're standing up a new web product and want to talk it through with someone who's shipped this stack to production a lot, book a call.
