Why we build on Next.js + React Server Components

Almost every greenfield product we’ve started in the last eighteen months has shipped on the same stack: Next.js with React Server Components, typed end-to-end, deployed on Vercel or a similar managed runtime, with a sensible data layer behind it. It’s become the default, and the question we get asked most often is why.

What the stack actually buys you

The pitch isn’t React per se — it’s the combination of three things you used to have to assemble yourself.

• Server-rendered by default. Pages are HTML on first paint. Search engines, social previews, low-bandwidth users, and accessibility tooling all work without ceremony. The interactive bits are still interactive — they just opt in.
• End-to-end TypeScript. A change to a database column flows up to the route handler, the server component, and the props of the React tree, surfacing as a compiler error before it ever lands in QA. The feedback loop is fast and the bug class is shrunk to almost nothing.
• One deployment, one mental model. Routing, data fetching, image optimisation, edge caching, and background functions all live inside the same project. There’s no “the API is in a different repo” tax.

Where it shines for client work

For an agency that builds bespoke software for SMEs and publishers, this stack hits a sweet spot. We can stand up a real, production-shaped product in days, not months. The hosting platforms we use take care of infrastructure that used to need a dedicated DevOps engagement. And when the client takes the codebase in-house — which we actively encourage when it’s the right time — they inherit something that any senior React developer can pick up.

The portfolio is a useful testbed. The relaunched LunaHR runs on it. Fund My Masjid runs on it. The Boutique Chalet Company’s deposit flow runs on it. Each is a different shape of product, and the underlying skeleton is recognisably the same.

Where we don’t use it

It’s a bad fit for a handful of jobs:

• Content sites where the client’s editorial team needs WordPress-grade authoring on day one. We still build plenty on WordPress and on headless CMS combinations like Strapi when that’s the right answer.
• Pure SPAs that live behind a login and don’t benefit from server rendering. A simpler React + Vite + a typed RPC layer is sometimes the cleaner choice.
• Compute-heavy backends — image processing pipelines, data ingestion, ML inference — which deserve a separate service, not a Next.js route handler.

The honest part

None of this is novel. The techniques have been battle-tested by very large products for several years now. What’s changed is that the toolchain has matured to the point where a small studio can adopt it without paying a tax in operations or hiring. That’s the bit that makes it worth defaulting to.

If you’re weighing up a new build and want a frank conversation about whether this stack — or a different one — is right for the problem, get in touch.