Hire Next.js developers

Next.js is the React framework most commercial web applications now run on, and hiring for it means hiring for the server and client boundary more than for React itself.

What Next.js actually is

Next.js is a framework built on React that supplies the parts React deliberately leaves out: routing, server rendering, data fetching, bundling and a deployment model. It is developed by Vercel, who also sell hosting for it, and that dual role is worth understanding when you read its documentation, because the recommended path and the commercially convenient path are not always distinguishable.

What you get in exchange for the framework's opinions is a great deal of infrastructure you would otherwise assemble yourself, and a clear answer to questions that otherwise consume weeks: where does routing live, how does a page get its data, what renders on the server, how does a build become a deployment. For most commercial projects that trade is worth making. For a small internal tool it is often more machinery than the problem requires.

The critical thing to grasp before hiring is that Next.js has been through a genuine architectural change. The older model put every page in a pages directory and fetched data through a small set of exported functions. The newer model organises the application around a router where components run on the server by default and opt into running in the browser. Both are in production in large numbers. They are different enough that experience in one does not straightforwardly transfer to the other, and a CV that says Next.js tells you nothing about which.

The part that separates seniors from mid-levels

The heart of the modern framework is that components run on the server unless they say otherwise. A server component can read a database, use a secret, and never ship a line of its own code to the browser. It cannot hold state, use an effect, or respond to a click. A client component can do all of those and pays for the privilege in bundle size. Everything difficult in a Next.js codebase comes from where somebody drew that line, and the most common mistake is drawing it too high, so that a single interactive element pulls an entire page into the browser.

Data fetching and caching are the second thing that separates levels, and the area where the framework has changed its own defaults more than once. Requests can be cached, revalidated on a timer, revalidated on demand by tag, or opted out entirely, and the same fetch behaves differently depending on where it runs and what else the route does. Developers who have only followed tutorials tend to know that caching exists. Developers who have shipped and operated a Next.js application can tell you about the time stale data reached production and what they changed so that it could not happen again.

The third area is rendering strategy per route, which is a commercial decision as much as a technical one. A marketing page that changes weekly should be static. A logged-in dashboard cannot be. A product page on a large catalogue usually wants to be generated on first request and then cached. Getting this wrong is expensive in both directions: unnecessary dynamic rendering costs money and speed on every request, and inappropriate static generation serves stale prices to customers.

Where Next.js is used

The label “Next.js developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Commerce storefronts

Category, product and checkout routes where server rendering and route-level caching carry both the search visibility and the conversion rate.

Marketing and content sites

Sites built against a headless CMS where most routes are static and the editorial team expects changes to appear without a rebuild.

SaaS application shells

Authenticated products where the marketing surface and the application live in one codebase and share a component library.

Multi-tenant platforms

Applications serving many customers from one deployment, where routing, theming and data isolation per tenant are the hard parts.

Migration targets

Teams moving off a client-rendered single-page application, usually for search visibility or first-load performance rather than for developer preference.

Edge-deployed applications

Workloads where parts of the response are computed close to the user, typically personalisation, localisation or access control.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Next.js versions are still supported

Next.js releases frequently and has changed significant defaults between major versions, so the version a codebase sits on tells you a lot about which patterns it uses.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 2 are still maintained and 6 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Next.js alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

React

The component layer underneath. Next.js decisions constrain React ones, not the other way round.

TypeScript

Effectively assumed in new Next.js work, particularly across the server and client boundary where props must be serialisable.

A headless CMS

Contentful, Sanity, Strapi or similar, supplying content to statically generated routes.

Prisma or Drizzle

Typed database access from server components and route handlers.

Tailwind CSS

The default styling approach in most current Next.js codebases.

Vercel, or a container platform

Deployment target. Where it is not Vercel, expect extra work on caching, image handling and middleware.

Playwright

End-to-end tests, which matter more here because so much behaviour depends on where code ran.

An auth library

Session handling across the server and client boundary, one of the most common sources of subtle bugs.

Related skills that frequently appear on the same specification: Node.js, WordPress, GraphQL, React, TypeScript.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Server and client component boundaries

The single most important judgement in a modern Next.js codebase and the clearest divider between recent and dated experience.

• Strong answer: Explains what forces a component to the client, keeps the boundary as low as possible, and can describe a case where they pushed it down and what it saved.
• Warning sign: Marks components as client-side by default, or cannot explain why a server component has no state.

Caching and revalidation

Where Next.js surprises people in production, and where stale data reaches customers.

• Strong answer: Distinguishes request caching from route caching, uses tag-based revalidation deliberately, and has a story about stale data in production.
• Warning sign: Describes caching as something the framework handles, or disables it globally to make a bug go away.

Choosing a rendering strategy per route

A commercial decision that developers are often allowed to make by accident.

• Strong answer: Picks per route against how often data changes and who sees it, and can explain the cost of getting it wrong each way.
• Warning sign: Applies one strategy across the whole application, or cannot say which routes in their last project were static.

What happens on a deploy that is not Vercel

Reveals whether they understand the framework or only the hosting product.

• Strong answer: Knows which features depend on platform support, and has configured image handling, caching and middleware somewhere else.
• Warning sign: Has never deployed Next.js anywhere but Vercel and assumes the difference is a configuration flag.

Authentication across the boundary

A reliable source of security bugs, because a check that runs only on the client is not a check.

• Strong answer: Verifies on the server, treats middleware as routing rather than as authorisation, and can explain where the session is read.
• Warning sign: Describes protecting a route by redirecting in a client component.

Bundle size and what they measured

Separates people who have shipped from people who have built locally.

• Strong answer: Names the analyser, can describe a dependency they removed or deferred, and knows what their largest route costs.
• Warning sign: Has never looked at a bundle, or assumes the framework handles it.

A migration they have run

Most substantial Next.js work in the market is migration work.

• Strong answer: Describes an incremental migration with both routers live, and what they learned about the order to move things in.
• Warning sign: Has only worked on greenfield projects and proposes a full rewrite as the obvious approach.

Warning signs in a Next.js codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Client components all the way down

• What you see: The client directive at the top of nearly every file, often added to fix one error.
• What it costs: The whole page ships to the browser, server rendering advantages disappear, and the framework becomes an expensive way to build a single-page application.
• The fix: Push the boundary down to the smallest interactive leaf. Pass server-rendered content through as children rather than importing it into a client component.

Fetching in a client effect on a server-capable route

• What you see: A component that could have fetched on the server instead fetching after it reaches the browser.
• What it costs: An extra round trip, a loading state the user did not need, and data that search engines may never see.
• The fix: Fetch in the server component and pass the result down. Keep client fetching for genuinely interactive updates.

Caching disabled globally to fix one bug

• What you see: A blanket no-store or force-dynamic applied across the application.
• What it costs: Every request recomputed, hosting cost up, response times up, and the original bug still there in a different form.
• The fix: Find the one fetch that was stale and tag it. Revalidate that tag when the underlying data changes.

Authorisation in middleware only

• What you see: Access control implemented as a redirect in middleware, with no check where the data is read.
• What it costs: A security hole, because route handlers and server actions can be called directly.
• The fix: Check authorisation where the data is accessed. Treat middleware as routing convenience, never as the boundary.

Secrets leaking through props

• What you see: Server-side values passed into client components because it was convenient.
• What it costs: Anything crossing that boundary is serialised into the page and visible to anyone who looks.
• The fix: Treat the boundary as a public API. Pass only what the browser is allowed to know.

One enormous layout

• What you see: A root layout that fetches everything and wraps the whole application in providers.
• What it costs: Every route pays for data it does not use, and nothing can be statically generated.
• The fix: Push fetching and providers into the segments that need them. Keep the root layout close to empty.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Next.js developer.

Junior

Builds routes and components inside an established Next.js structure. Needs the rendering strategy and data-fetching pattern decided for them.

Mid-level

Owns a feature across the server and client boundary, including its caching behaviour. Can debug a hydration mismatch without guessing.

Senior

Decides rendering strategy per route, owns the caching model, and can justify the deployment target. Able to run an incremental migration without stopping delivery.

Staff

Owns the application's performance budget, its caching contract and its relationship with the hosting platform, including the exit path if that platform changes terms.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New commercial web application

• Usual team: Two to three developers with one senior owning rendering and caching decisions.
• What governs it: The routing and caching model set in week one is very expensive to change in month six.

Migration from a client-rendered application

• Usual team: Two developers, at least one who knows the outgoing codebase.
• What governs it: Scoped by route count and by how much of the old application has tests, not by screens.

Headless CMS build

• Usual team: One senior developer plus a content modeller.
• What governs it: The content model decides the difficulty. A model designed for editors rather than for the framework is usually the better trade.

Performance and cost remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Starts with measuring render counts and hosting spend per route. Most savings are in a handful of routes.

Platform migration off Vercel

• Usual team: One senior developer plus infrastructure support.
• What governs it: Governed by which platform-specific features are in use. Image handling and middleware are usually the expensive parts.

Migration work you may actually be hiring for

A large share of Next.js work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

The pages router to the app router

• Why teams do it: Server components, streaming and a data-fetching model that removes most client-side fetching code. Also where all new framework work is going.
• What to watch: Both routers can run side by side, so migrate route by route. Shared layout, authentication and data-fetching helpers usually need to exist in two forms during the transition, and teams that do not plan for that duplication tend to stall halfway.

A client-rendered single-page application to Next.js

• Why teams do it: Search visibility, first-load performance and the cost of shipping a large bundle to every visitor.
• What to watch: Anything that assumes a browser breaks on the server. Budget for the data layer as well, because fetching patterns that worked in the browser often become the bottleneck once they run per request.

A traditional CMS front end to Next.js with a headless CMS

• Why teams do it: Editors keep a familiar interface while the front end gets modern performance and a component model.
• What to watch: The content model is the whole project. Modelling content around the components you happen to have built now produces something editors cannot use in a year.

Vercel to a container platform

• Why teams do it: Cost at scale, data residency requirements, or consolidating onto existing infrastructure.
• What to watch: Image optimisation, middleware, incremental regeneration and cache revalidation all need explicit replacements. Verify each one under load before switching traffic, not after.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Next.js developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which router the existing application uses, or which one a new build should use. This is the first filter on the candidate pool.
• Where the application is deployed now and whether that is fixed. Vercel-specific experience is either irrelevant or essential depending on the answer.
• Which routes need fresh data and which can be cached, at least roughly. This drives more architecture than anything else in the brief.
• What the content source is, and whether non-engineers need to publish without a deploy.
• Whether authentication is in scope, and if so what already exists. Session handling across the server and client boundary is where the subtle bugs live.
• Whether this is new development or a migration, and if a migration, whether the existing application has tests.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Next.js work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Next.js developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Next.js developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Next.js frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Experience only in the older pages router. Ask directly which router their last production work used. This is the largest single gap in the current Next.js market.

Framework knowledge without React depth. Test React state and rendering separately. Next.js hides these until a performance problem makes them visible.

Vercel-only deployment experience. Only matters if you deploy elsewhere, and matters a lot if you do. Ask early rather than at handover.

No production operating experience. Ask what broke after launch. Caching and revalidation problems only appear under real traffic and real editing.

Hiring Next.js developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Next.js developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Is Next.js overkill for a small site?

Often, yes. If the site is a handful of pages with no authentication and no dynamic data, a simpler static generator will be faster to build and cheaper to run. Next.js earns its complexity when you have genuine server-side needs: authentication, per-user data, a large catalogue, or content that has to be fast and fresh at the same time.

Do I need a Next.js developer or a React developer?

If the application is already on Next.js, hire for Next.js, because the hard decisions are framework decisions. If you are choosing a stack now, a strong React developer will pick up Next.js faster than a Next.js developer without React depth will pick up the parts the framework hides.

How do I check which router version someone has used?

Ask what file their last route lived in and how it got its data. The two models have visibly different answers, and the question is specific enough that it cannot be answered from general familiarity.

Are we locked into Vercel?

Not locked, but the path of least resistance runs through it. Next.js deploys to containers and other platforms, and several features that are automatic on Vercel need configuration elsewhere, particularly image optimisation, middleware and cache revalidation. If leaving is a foreseeable requirement, decide it early and hire someone who has deployed it elsewhere.

Why is our Next.js site slow when the framework is supposed to be fast?

In our experience it is nearly always one of three things: too much of the page is a client component, data is being fetched in the browser that could have been fetched on the server, or the route is rendering dynamically when it could be cached. All three are diagnosable in a morning by someone who knows where to look.

How long does a migration from the older router take?

It depends almost entirely on how much the application relies on client-side data fetching and on whether it has tests. Both routers can run in the same application, so the work is incremental and delivery does not have to stop. Teams that try to convert everything before shipping anything are the ones that stall.

Should the marketing site and the product share a Next.js codebase?

It works well when the same team owns both and they share a design system. It works badly when marketing needs to publish without waiting for an engineering deploy. If that is the situation, the better split is usually a headless CMS feeding the marketing routes rather than two separate codebases.

What does a Next.js developer need from us on day one?

Environment variables that work locally, access to the real content source rather than fixtures, and a decision about the deployment target. The third one is the one teams most often leave open, and it quietly constrains every architectural choice made before it is settled.