There is a job listing template that recruiters copy-paste every week: "Hire Next.js developers. 5+ years of Next.js experience required." Read it closely and it asks for something that does not exist. Next.js the brand has been around since 2016, sure. But the Next.js those listings actually mean — the App Router, React Server Components, the whole server-first mental model that makes the framework distinctive today — has only been production-stable since the 13.4 release in May 2023. That is roughly three years of possible experience, in a thing whose defaults changed again between versions 14 and 15. "Five years of App Router" is a unicorn you invented in the requirements doc.
The listing isn't just wrong on arithmetic. It's wrong on what it's hiring for. And the mistake is baked into the phrase itself.
The phrase gives away the error
"Hire Next.js developers" treats a framework as a profession. It is not. Next.js is a fairly thin opinionated layer that sits on top of React and Node, wiring together routing, rendering, bundling, and a deployment story. It is a very good layer. It is not a discipline. When you hire for it as a specialty, you are optimizing your candidate filter for the one thing that ages fastest — the current syntax of a fast-moving framework — instead of the things that don't age: how the web renders, how HTTP caching works, how you keep a database from falling over under load.
The tell is that a strong React engineer with real systems sense can be productive in Next.js in about a week. A "Next.js developer" who learned the framework as their first and only frame of reference often cannot debug the layer underneath it when the abstraction leaks — and this abstraction leaks constantly. You are not hiring for the happy path. You are hiring for the 2 a.m. incident where the framework's caching did something you didn't ask it to.
What you're actually buying when you buy "Next.js"
Modern Next.js is not a template engine anymore. The App Router shipped React Server Components into the mainstream — components that run on the server, never ship their JavaScript to the browser, and interleave with client components in ways that break most developers' intuition about where code executes. This is genuinely powerful and genuinely hard. The number of engineers who can confidently answer "is this running on the server or the client, and why" for an arbitrary component tree is far smaller than the number who list Next.js on a résumé.
The framework also moves. The App Router arrived as the future while the Pages Router remained the thing most production apps were actually built on, leaving teams straddling two routing paradigms in the same codebase. Major versions ship roughly yearly and they are not cosmetic. That churn is the point: the half-life of "knows the current Next.js API" is measured in months. If that is your hiring criterion, you are re-hiring every year.
The caching model is where the framework tourists drown
If you want one concrete test of whether someone understands Next.js or merely uses it, ask them to explain its caching. The App Router stacks several distinct caching layers on top of each other — request memoization within a render, a persistent data cache for fetches, a full-route cache for rendered pages, and a client-side router cache — each with its own invalidation rules and its own ways of surprising you. Most "it works on my machine, stale in production" bugs live in the gap between those layers.
Then the defaults moved. Next.js 14 cached aggressively by default — fetches and routes were cached unless you opted out, which quietly served stale data to teams who never knew they'd opted in. Next.js 15 reversed it: fetches and GET route handlers are no longer cached by default. That is not a patch note. That is the framework changing the fundamental behavior of every data fetch in your app between two major versions. An engineer whose knowledge is "what Next.js does by default" now holds knowledge that expired. An engineer who understands caching as a concept reads the changelog, shrugs, and adjusts. Guess which one you want owning your production build.
The deployment question nobody puts in the job post
Next.js is built by Vercel, and the frictionless path — push to git, get a deployed app — runs through Vercel's platform. That path is genuinely excellent for prototypes and genuinely expensive to be surprised by. The recurring horror story in this ecosystem is a team that shipped on the default deployment, went viral or just grew, and met a bandwidth and function-invocation bill that bore no relationship to what the same traffic would cost on infrastructure they controlled. Self-hosting Next.js is possible and increasingly well-supported, but it is precisely the part that framework-only hires tend not to have touched, because the whole pitch was that they didn't have to.
So the deployment target is an architecture decision with a price tag, and it belongs in the hiring conversation even though it never appears in the job title. "Can build pages in Next.js" and "can reason about what those pages cost to serve at scale, and where they should run" are different skills. Only one of them shows up on the invoice.
So who do you actually hire
You hire a senior full-stack engineer who understands rendering, caching, and infrastructure, and who happens to use Next.js as one tool among several. The framework should be a line in their toolbox, not the headline of their identity. The signal you want is depth in the layers beneath the framework — React's rendering model, the network, the database, the deployment economics — because those are what remain constant while Next.js rewrites its own defaults every year.
This is not a neutral observation for us. At EltexSoft the largest group is full-stack — the backend discipline of Laravel and PHP paired with React on the front — running multi-year SaaS builds where the same team owns the app for years, not a quarter. React and Next.js sit inside that practice as tools, deployed by the engineers who also write the API and own the infrastructure, not handed to a separate framework specialist. Every one of those engineers has at least five years of production experience, and every pull request is reviewed by another senior before it merges. That structure exists specifically because the person who can reason about the whole stack catches the caching bug that the person who only knows the framework ships to production.
That is also why we don't staff by framework badge. The engineer who understands the systems learns Next.js's next breaking change over a weekend. The engineer hired for "Next.js" and nothing beneath it needs re-hiring when the framework moves — which it will, on schedule.
And when Next.js is the wrong answer entirely
Committing to a real position means saying this out loud: a lot of teams reaching for Next.js should not be. If you are building a mostly-static marketing site, the full App Router and its server runtime are overhead you will pay for in complexity and hosting. If you are building a dashboard-heavy internal tool that lives behind a login and never needs SEO or server rendering, a plain single-page React app on a CDN is simpler, cheaper, and harder to misconfigure. Next.js earns its complexity when you genuinely need server rendering, streaming, and tight data-fetch control at the edge of a large public app. Reaching for it because it is the default is how teams inherit four caching layers to solve a problem they never had.
An engineer worth hiring will tell you that before you sign off on the stack. A "Next.js developer" — someone whose value proposition is that you chose Next.js — has no incentive to. That asymmetry is the whole argument.
The retention argument runs through everything we write about staffing; our full breakdown of when staff augmentation is worth it is the fullest version of it. For the practical side, see our staffing services.
The position, stated plainly
Delete "hire Next.js developers" from your requirements. Not because Next.js is bad — it is one of the best things to happen to React — but because the phrase selects for the wrong person. Hire senior engineers who understand how the web renders and how data gets cached, who can defend a deployment decision by its cost, and who treat Next.js as a sharp tool they know when to put down. Those people will run circles around the framework specialists precisely when it matters: the incident, the version bump, the bill. Hire the engineer. The framework is just what they happened to type this year.