Skip to content
All articles
Web Development

Why I Reach for Next.js on Most Client Work

Clients don't care what framework their site is built with, and they shouldn't have to. Here's why Next.js is usually my default anyway - and when it isn't.

Daniel Campbell-WhiteDaniel Campbell-White 20 April 2026 2 min read
Share

Clients almost never care what framework their website is built with. Why would they? What they care about is that it's fast, it ranks, it doesn't break, and they can update it without ringing me every five minutes.

Next.js happens to be a really good tool for hitting all four, which is why it's where I usually start. Here's the honest reasoning, not the marketing version.

It's fast without me having to fight for it

Next.js renders pages on the server or at build time, so a visitor gets actual HTML straight away instead of staring at a blank screen while a load of JavaScript boots up. Add automatic code-splitting and image optimisation on top and you get a quick site mostly by default. I'd rather spend my time on the build than clawing back performance I lost by picking the wrong tool.

It plays nicely with SEO

Because pages are rendered properly, search engines see real content, not an empty shell. Metadata, canonical URLs, sitemaps, structured data - all the technical bits that so many sites get wrong - are straightforward to handle. That's a big deal for any site that needs to be found.

It grows with the business

This is the underrated one. The same framework runs a five-page brochure site and a proper web app. So when a client comes back a year later wanting a customer login or a booking system, I'm extending what's there, not binning it and starting over. That saves them money and saves me a rebuild.

When I don't use it

Plenty of times, honestly. If it's a tiny static one-pager going nowhere, Next.js is overkill and something lighter does the job. If a team needs a mature, polished CMS and doesn't need a custom front end, I'll point them at the right tool for that instead - WordPress, Umbraco, whatever fits. I've worked across enough stacks to not be precious about it.

That's really the point. The framework is a means to an end. My job is to pick the thing that gets you the best result and then build it properly - not to use my favourite toy because it's my favourite toy.

#Next.js#React#Architecture

Found this useful? Pass it on.

Share

Want this kind of thinking applied to your website?

Get in touch and let's talk about your goals.