Building a Website in 2026

In the ever evolving field of Web Development, choosing a Tech Stack is far from straightforward. Every year so far I've answered that with a single list. This year I can't. I shipped four brochure sites, several production applications, and four mobile releases, and they do not share one stack. They share a type of stack, picked for what the project actually was.

Frontend

For anything that's a real application (user accounts, a backend behind it, actual state to manage), Next.js is what I reach for first this year. Housemaster and Costhub are both the same shape under the hood: every App Router page is a Server Component by default, "use client" is reserved for the leaves that actually need it, and mutations live in "use server" actions that get Zod-parsed before they touch anything. A server action is a public boundary the same way an API route is, and I stopped trusting form data by cast alone.

Mobile is where the biggest change happened this year, and it's less about the framework than the pipeline around it. Expo carried four app releases in 2026, mostly because of EAS. Build profiles for dev, preview and production live in one eas.json, eas build --auto-submit goes straight to TestFlight without me touching Xcode, and eas init stands up a brand-new app's cloud project in a single command. That pipeline is why a side project like Spendwise could go from a ported prototype to a TestFlight build in the same week. Releasing was the bottleneck. Flutter is still carrying one app, and it's a good framework, but every release on it this year still meant a manual trip through Xcode and the Play Console. Expo has turned that into a solved problem.

The eas.json I keep around looks like this. Three profiles, submit wired for production, nothing clever:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  },
  "submit": {
    "production": {}
  }
}

Then eas build --profile production --auto-submit. That is the whole "open Xcode" step.

For brochure or marketing sites (this one included, plus three others I built or rebuilt this year), Astro is still it, but I hold it more strictly now than I did in 2025. A page starts as plain markup with a <script> tag, and only earns a Vue island if it needs real client-side state. A contact form and a portfolio filter both stayed vanilla JavaScript this year, once I actually paid attention to when an island was earning its keep versus when it was a habit.

Angular hasn't gone anywhere, it's just no longer the default I open first. NgRx's SignalStore replaced the older store pattern in most of what I still build with it, I gave a conference talk on it, and Angular v21's move toward zoneless and Signal Forms is the part of the framework I'm most impatient to use in production. Next.js took the applications and Expo took mobile this year, that's all.

Headless CMS

I dropped the CMS category this year. I ran Strapi behind this blog for close to three years and turned it off in 2026. The full story, including the two bugs that nearly slipped through, is here: moving this blog off Strapi.

That is specific to this site, though. If people who aren't developers are writing your content, or you need scheduling and review across a team, a real CMS is still doing work that a git repo won't do for you.

Backend

FastAPI is still my default the moment Python or anything AI-adjacent is involved. It's what's behind Housemaster, Costhub and most of the other backend services I actually run day to day.

The real addition this year is Spring Boot. I spent a good part of 2026 co-authoring the second edition of Spring Boot and Angular (Spring Boot microservices paired with Angular v21, out this September), and writing twenty-one chapters about a stack makes you trust it more than a year of casual opinions would.

You can pre-order it on Amazon. For enterprise Node work I'd still point people at NestJS. Go with Echo remains the answer once raw response time is the actual constraint rather than a nice-to-have.

Deployment

Where things go live depends on the project too. Brochure sites still go to Netlify. Still the first thing I reach for there, now paired with a build step that generates a branded OG image per page instead of shipping a raw screenshot, and cookieless analytics gated behind an environment flag instead of on by default.

The applications live elsewhere. Housemaster is on AWS, on EKS. It runs as a standalone next build server. Kubernetes probes hit /api/health, which is static, so they do not render a page or call the backend. Pages and server actions still go out to FastAPI, and every outbound call is wrapped in a timeout so a slow backend can't hang a render. Costhub's frontend is the same Next.js shape, on Vercel.

Mobile has its own story now, EAS end to end instead of a netlify deploy. That's a category I didn't need an opinion on until this year.

👉🏻 Have you used any of these? What did your stack look like this year?