Frontend
Next.js
The React framework this site is built on.
Next.js in practice
A React framework that settles the questions a React application otherwise has to answer for itself. Routing comes from the file system, rendering happens on the server unless a component opts out, and fetching, caching and revalidation belong to the framework rather than to a library somebody chose in a hurry. A page can be static, rendered per request, or regenerated on a schedule, and moving between those is a change to that page rather than a change to the architecture holding it.
We build marketing sites, content-led sites and application front ends on it, this one included. Server rendering is what makes pages arrive as HTML a crawler or an answer engine can read without executing anything first, which is the practical difference between a site that gets indexed and a site that hopes to be. Routing, metadata, image handling and a build that refuses to complete on a type error all come with the framework, so the effort goes into the content and the interface instead of into assembling a toolchain.
You adopt its rendering model, not merely its router. The boundary between server and client components shapes how state, context and third-party libraries get organised, and any library assuming it can run anywhere will discover that it cannot.
Major versions have asked for genuine migration work rather than a version bump. The move to the newer routing model changed layouts and data fetching together, and any project on it should treat upgrades as scheduled work with a budget.
It is aimed squarely at one hosting platform. Self-hosting is supported and entirely achievable, and you take on the operational parts that platform had been handling quietly on your behalf.
Values needed at build time are baked into the output, so one artefact cannot be promoted unchanged between environments that differ in those values. That constraint has to be understood before the deployment pipeline is designed around it.
It is more framework than a small brochure site requires. Where there is no dynamic behaviour justifying the machinery, a plain static generator leaves less to maintain and fewer things to upgrade every year.
FAQ
Next.js questions we hear often
Do we need Next.js, or is plain React enough?
Plain React is enough for an application behind a login where nothing needs to be indexed by anybody. Once pages have to arrive as HTML for search, or the site mixes static content with genuinely dynamic sections, the framework is doing work you would otherwise write and then maintain yourself. The deciding question is whether anything here needs finding rather than logging into.
Can we host it anywhere?
Anywhere that runs Node, though the experience varies more than the marketing suggests. A fully static export will sit on any file host, and the moment server rendering, image optimisation or route handlers are in play you need a runtime and a plan for operating it. Check what your hosting genuinely provides before the architecture assumes otherwise.
How much work is a major version upgrade?
Somewhere between an afternoon and a project, depending which one. Point releases are routine and largely uneventful. Versions that changed the routing and rendering model asked for structural change, and a codebase that skipped several at once compounds all of it. Upgrading regularly costs far less than upgrading eventually, which is advice everybody agrees with and few follow.
Is server rendering worth the complexity for a content site?
For anything that needs to be found, yes. A page assembling itself in the browser is at the mercy of whether a crawler chose to execute the script that day, and answer engines are less forgiving about that than search engines have become. For a purely internal tool with no discovery requirement the calculation reverses and simplicity should win.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.