Why we build with Next.js — and where we do not.

Next.js is the framework behind most of what we build, including this site. That is a defensible choice rather than a fashionable one, but the reasons that matter to a business are not the reasons developers usually give. This is the version of the argument that affects your budget, your rankings and your ability to hand the project to someone else in three years.

The problem it actually solves

A plain React app renders in the browser: the visitor downloads a JavaScript bundle, the bundle runs, and only then does content appear. That is fine for an app behind a login and bad for anything that needs to be found, because the first thing a crawler or a slow phone receives is an empty page. The standard workaround is bolting server rendering onto React by hand, which is a genuine engineering project with its own maintenance bill.

Next.js ships that as the default. Pages render on the server, the browser receives real HTML immediately, and JavaScript only takes over for the parts that actually need interactivity. You get app-grade interactivity where you want it and document-grade indexability everywhere else, without maintaining the plumbing yourself.

The parts that pay for themselves on every project

Images are the largest thing on most pages, and Next.js handles them properly without a plugin: modern formats, correct sizes per device, lazy loading below the fold and reserved space so nothing jumps while loading. That single feature is usually worth more to a Core Web Vitals score than any other optimisation on the list.

Alongside it: route-level code splitting so a visitor to your contact page does not download the checkout logic, font subsetting so text renders without a flash, and metadata handled as data rather than as tags someone remembers to update. None of these are exotic. They are the things that get skipped under deadline pressure on a hand-rolled stack, and here they are the default.

It puts SEO controls where we can actually reach them

Per-page titles, canonical URLs, hreflang across multiple language deployments, structured data, sitemaps generated from real content, redirects when a slug changes — all of it is code we own, versioned alongside everything else. On a hosted platform, several of those are whatever the vendor decided to expose this year.

That matters more now that AI answer engines read the same signals. Clean server-rendered HTML with correct schema is what both a crawler and a retrieval system need, so the technical work behind ranking and the technical work behind getting cited are the same work.

Being on the mainstream path is a feature, not vanity

Next.js is the most widely used React framework, which has a boring but real commercial consequence: the documentation is thorough, the security patches are frequent, most problems you hit have already been solved publicly, and if you ever replace us you will not struggle to find someone who knows the codebase's conventions. A niche framework can be technically lovely and still leave you with a hiring problem.

Long-term supportability is the part clients feel years later. We would rather build on something with a large maintained ecosystem than on the most elegant option with four contributors.

Where Next.js is the wrong tool

If you need a marketing team editing content daily without developer involvement, WordPress and its editor ecosystem is often the better answer — our WordPress Starter exists for exactly that reason. If the site is a handful of static pages that will barely change, Next.js is more machinery than the job needs, and hand-written HTML or a static generator is cheaper to build and to host.

It is also the wrong choice if your hosting is locked to shared PHP with no Node runtime, or if an in-house team maintains everything and knows a different stack well. Handing a team a framework nobody there can maintain is a worse outcome than a technically inferior stack they can.

How to tell which side of the line you are on

One question does most of the work: does the site need to be both discoverable and interactive? Product configurators, multilingual catalogues, portals, booking flows, anything with a real front end that also has to rank — that is where Next.js earns its cost. A brochure that needs to exist and load fast does not need it, and we will tell you so rather than sell you the harder build.