Why we build with Next.js 16 (and host on Vercel)

Our reasoning for picking Next.js 16 as the default for almost every site we ship — what RSC unlocks, why Turbopack matters in dev, and what we still reach for Astro for.

We default to Next.js 16 with the App Router for almost every web project we ship — marketing sites, e-commerce, dashboards, internal tools. This post is the reasoning, because "why this stack" is the question we get most.

React Server Components are the unlock

For 10 years, React shipped JavaScript to the browser to render UI. That was fine for apps where every component needed interactivity, terrible for marketing pages where 90% of components are static.

RSC flips it: components render on the server by default and ship zero JavaScript to the client. You add "use client" only on the components that need state, effects, or browser APIs. The result: a typical TheNodeNest marketing homepage now ships about 90 KB of JavaScript total — down from 400 KB+ on a similar Pages Router site.

App Router is the right model

File-system routing in app/, layouts that compose, loading states with Suspense, server actions for forms, generateMetadata for per-route SEO. It feels like React the way it should have been from the start, and it makes the framework opinionated enough that you stop reinventing routing on every project.

Turbopack in dev makes iteration fast

Hot reload is sub-100ms on most edits. The full project rebuild on this site (15 routes, ~30 components) is under 4 seconds. For comparison, our previous Pages Router project of similar size took 18 seconds with Webpack.

The Turbopack build path on Windows requires the @next/swc-win32-x64-msvcbinary — there is a small risk if your CI environment runs on an unusual platform, but Vercel and most CI providers handle it.

Vercel is the path of least resistance

We host on Vercel for the same reason we use Next.js — it's the smoothest path from git push to a working preview URL. Image optimisation, edge caching, ISR, edge functions all work without configuration. The Cape Town and Lagos PoPs cover Kenyan latency well.

Cost is the trade-off. Vercel's pricing climbs sharply once you exceed the Hobby tier, especially for image optimisation and bandwidth. For sites with heavy image traffic we recommend Cloudflare Pages + R2 — cheaper and almost as smooth.

What we still reach for Astro for

Marketing sites with zero interactivity (a brochure site, a 2-page launch landing) we sometimes ship in Astro. Astro's zero-JS-by-default is even more aggressive than Next.js, and the build output is smaller. The ceiling is lower (no React state islands without a wrapper), but for static-first projects it is excellent.

What we don't use, and why

  • Gatsby — slow builds, complex GraphQL layer that we rarely need, ecosystem stagnated post-Netlify acquisition.
  • Remix— great framework, but we're already deep in Next.js tooling and the gain doesn't justify the switch for client work.
  • Plain React + Vite— still our pick for embedded admin SPAs that don't need SSR. Rarely the right call for a public site.

The TL;DR

Default to Next.js 16 with App Router. Host on Vercel until cost forces you to Cloudflare. Use Astro for static-only marketing. Use Vite + React for embedded SPAs.

See our website service for everything we build with this stack.

Chat on WhatsApp