Hire Next.js Developers

Next.js earns its place when a product needs both an application and a set of pages that have to rank — a marketplace, a catalogue, a documentation-heavy tool — and you would otherwise run two codebases to get there. It stops earning its place when a purely internal application inherits the rendering complexity without ever needing the search benefit.

In the App Router there is really only one question, asked repeatedly: where does this code run, and what does it cost to be wrong about that. Everything else — server components, actions, streaming, revalidation — is a consequence of the answer.

Caching is the framework’s best feature and its worst failure mode

Next 15 changed the default so fetch is no longer cached unless you say so, which was the right call: the previous default produced pages that were correct in development and stale in production, and the mechanism was invisible in the code. Teams still carry habits from before that change.

The pattern we use is explicit revalidation per request rather than a blanket page setting — a listing that tolerates half a minute of staleness declares that on the fetch that loads it, and the next data source on the same page can declare something different. Blanket settings are convenient and they are also why “why is this page showing yesterday’s price” takes two days to diagnose.

One related judgement is worth stating because it is easy to get backwards: if the framework is already caching a response, do not also serve it from a CMS’s own edge cache. Two caches means two independent staleness windows, and the union of them is what your users experience.

What actually changes when you migrate from the Pages Router

Not the folder names. The three real changes are that data fetching moves into the component that needs it, that “client” becomes something you opt into at a boundary rather than a default, and that several APIs became asynchronous — in Next 15, route parameters and search parameters arrive as promises that have to be awaited.

Migrate route by route with both routers live rather than in one branch. The App Router and the Pages Router coexist, which means the migration can ship in pieces and be judged in production, and a route that turns out to be harder than expected does not hold the other forty hostage.

Where Next.js is the wrong choice

For a marketing site or documentation with no application behind it, a static generator produces a better result for less work and less runtime. We build our own site that way deliberately: the output is HTML on disk, there is no server to keep alive, and every crawler — including the answer engines, none of which execute JavaScript — gets the full text on the first request.

For a purely internal tool behind a login, the search advantages are worth nothing and the rendering model is pure additional complexity. A plain single-page application with a boring API is cheaper to build and much cheaper to debug.

And if the team’s deployment target is a container on infrastructure they run themselves, be honest that the smoothest Next.js experience is on the platform that develops it. Self-hosting works, but image optimisation, incremental revalidation and caching all need deliberate configuration that the managed platform supplies for free.

What we interview for

Ask a candidate to explain what runs on the server and what ships to the browser in their last project, and how they knew. Then ask what they cached, for how long and what invalidates it. Engineers who have operated an App Router application answer precisely. Those who have only followed a tutorial describe the folder structure.

Two follow-ups tend to settle it:

• A secret was read in a component that later gained an event handler. What stops that secret being in the client bundle, and how would you find out if it already is.
• A page shows stale data for one user and fresh data for another. Name three mechanisms that could cause it.

The first is a real class of incident, not a puzzle — the boundary between server and client is a security boundary, and it moves when someone adds an onClick.

What we watch for in review

Server actions with no validation on the input, because an action is a public endpoint whether or not it looks like one. useEffect fetching data that a server component could have loaded before the page rendered. And the quiet one: a shared utility imported by both a server and a client module, dragging a server-only dependency into the browser bundle and inflating it by an amount nobody attributes to that change for months.

We also insist on knowing the build’s own numbers. If a candidate cannot say roughly what their first-load JavaScript was, they were not treating the rendering model as a performance decision — which is the entire reason to choose this framework over a plainer one.