How to Vet a Senior Next.js Developer for a Replatform or Recovery Project

Hiring a Next.js developer is easy if the work is small, isolated, and low risk. You need a page built, a component tidied, or a bug fixed in a codebase where the direction is already clear. Plenty of capable developers can help with that.

Hiring someone for a replatform, migration, production recovery, or technical SEO problem is different. The job is not "can this person write React?". It is "can this person make good calls when routing, rendering, caching, content, deployment, search visibility, and business pressure all collide?"

That is the part many hiring processes miss. They ask framework trivia and get polished answers. They look at a GitHub profile and see tidy demo projects. They ask whether the candidate has used the App Router, Vercel, or Contentful, and the answer is yes. None of that proves they can protect a live platform.

For senior Next.js work, you need to assess judgement under production constraints.

Start with the Job You Actually Need Done

"Next.js developer" is too broad to be a useful hiring brief.

A developer building a greenfield marketing site, an engineer migrating a React single‑page application to server‑rendered routes, and a consultant recovering traffic after a botched replatform are all doing Next.js work. They are not doing the same job.

Before you assess people, describe the situation honestly:

• Are you building a new product platform?
• Are you moving from React, Gatsby, WordPress, Drupal, Shopify, or another legacy front end?
• Are rankings, crawlability, or Core Web Vitals already damaged?
• Is the platform breaking only in production?
• Is the team struggling with App Router caching, hydration errors, route generation, or Vercel builds?
• Is the missing piece hands‑on delivery, architecture direction, or senior review?

The more serious the project, the less useful a generic skills checklist becomes. You want evidence that the developer can understand the shape of the risk.

React Skill is Necessary, but Not Enough

Next.js is built on React, so a weak React developer will not magically become strong because the framework does more for them. They still need component design judgement, state ownership discipline, accessibility awareness, debugging habits, and a decent feel for browser behaviour.

But React skill is only the base layer.

The official React documentation describes Next.js as a framework that supports full‑stack React applications, and the React guidance on starting a new project points developers towards frameworks for routing, data fetching, and server behaviour. That matters because Next.js projects are not just React projects with a nicer router. The framework changes where work runs, when data is fetched, how output is cached, and what the browser receives.

A strong Next.js developer should be able to explain:

• which parts of the interface render on the server and which hydrate in the browser
• when static generation is useful and when it creates stale content risk
• how redirects, canonical URLs, and route changes affect search visibility
• how data fetching affects performance and cache behaviour
• why a route can work locally and fail during a production build
• what should be tested in rendered output rather than source code

If they talk only about components, props, and Tailwind classes, they may be a good React developer. They may not be the right person to lead a high‑risk Next.js project.

Ask About Rendering Without Turning It into a Quiz

Rendering is where many Next.js hiring conversations become too shallow.

You do not need someone to recite every feature name. You do need them to reason about trade‑offs. Ask them to walk through a product listing page, article page, account page, or campaign landing page and explain how they would choose the rendering model.

The Next.js Server Components documentation is clear that layouts and pages are Server Components by default in the App Router, and that the framework can fetch data, render UI on the server, cache output, and stream work to the client. A senior developer should be comfortable with that model, but also aware that it introduces new failure modes.

Good signs:

• They ask how fresh the data needs to be.
• They separate public content pages from authenticated product or account flows.
• They mention what must be present in the initial HTML for search and sharing.
• They talk about cache invalidation as part of content operations, not an afterthought.
• They understand that Client Components can still be part of server‑rendered output before hydration.

Weak signs:

• They treat server‑side rendering as automatically better.
• They suggest turning everything dynamic because it feels simpler.
• They use "static" to mean "never changes".
• They cannot explain what might cause a hydration mismatch.
• They cannot connect rendering choices to SEO, performance, or editor workflow.

The point is not whether they choose the exact answer you had in mind. The point is whether they expose the trade‑offs before committing to an implementation.

Test Production Debugging, Not Just Greenfield Building

Replatform and recovery work rewards people who can find the first real failure.

Ask for a debugging story. Not a glossy success story. A real one. What broke? What evidence did they collect? What did they rule out? What did they change first? How did they know the fix worked?

For Next.js, useful debugging territory includes:

• failing Vercel builds
• environment variable drift
• static generation failures
• stale content after a CMS publish
• hydration errors
• middleware or redirect loops
• canonical or sitemap mistakes
• client‑side exceptions that only appear after a release
• performance regressions caused by script cost or data fan‑out

The Vercel build troubleshooting guide is a good example of the sort of evidence a production investigation needs: logs, framework settings, resources, build output, and environment assumptions. Someone senior should know how to work from evidence rather than guess from symptoms.

If their debugging process starts with "I would rewrite it", be careful. Sometimes a rewrite is right. Often it is an expensive way to avoid understanding the system.

For SEO‑Sensitive Work, Ask About Rendered Evidence

If the project has a search visibility risk, do not hire someone who treats SEO as metadata.

Technical SEO on a JavaScript site is not just title tags and descriptions. It includes crawl paths, rendered HTML, internal links, canonical consistency, redirects, structured data, status codes, and whether important content can be discovered without relying on fragile client‑side behaviour.

Google's JavaScript SEO basics explains that Google uses rendered HTML for indexing and that server‑side or pre‑rendering can still help users and crawlers. That should not be controversial to a senior Next.js developer.

Ask how they would validate a migration before and after launch.

Strong answers will mention:

• crawling old and new URLs
• checking redirect intent, not only redirect status
• comparing rendered output against the previous site
• validating canonicals, robots directives, and sitemap inclusion
• checking structured data against visible content
• watching Search Console and logs after release
• keeping a rollback or patch‑forward plan ready

Weak answers will reduce everything to "Next.js is good for SEO". It can be. It can also ship thin HTML, broken canonicals, missing links, stale generated pages, and routes that are beautiful to users but confusing to crawlers.

Portfolio Projects Need Context

A portfolio can help, but only if you ask what it proves.

A polished personal project may show taste and initiative. It does not prove the person can work inside a messy platform with legacy redirects, stakeholder pressure, content dependencies, and release risk. A big brand name on a CV may show exposure. It does not prove they owned the hard decisions.

Ask for context:

• What part did you personally own?
• What trade‑off did you have to defend?
• What constraint made the work difficult?
• What changed after launch?
• What did you measure?
• What would you do differently now?

For senior work, the explanation matters more than the screenshot.

I would rather hear a thoughtful account of a difficult migration than see a perfect demo app with no production scars. Good senior engineers can describe the problem space. They can tell you where the awkward bits were. They know which decisions were technical, which were organisational, and which were simply time pressure wearing a technical costume.

Backend Experience Matters When the Front End Owns Platform Behaviour

The generator‑style question is usually, "Do Next.js developers need backend experience too?"

The honest answer is: not always, but they need enough server‑side judgement for the work they are taking on.

A developer does not need to be a database specialist to build a content‑heavy website. They do need to understand request and response behaviour, caching, status codes, authentication boundaries, API contracts, environment variables, server logs, and deployment behaviour.

The Next.js caching documentation is a useful reminder that modern Next.js applications involve several caches, including request memoisation, data caching, full route caching, and client‑side router caching. A developer who does not understand those layers can accidentally turn a simple content update into an operational mystery.

For a replatform or recovery project, I would check whether the developer can talk comfortably about:

• how data moves from CMS or API to rendered page
• where stale data can come from
• how environment‑specific behaviour is controlled
• how build‑time and request‑time work differ
• where logging and observability should exist
• how redirects and headers are emitted

They do not need to own every backend system. They do need to avoid pretending the browser is the whole product.

Watch for Cheap Confidence

The main red flag is not lack of knowledge. Everyone has gaps.

The red flag is cheap confidence: certainty without questions, promises without evidence, and framework enthusiasm without production caution.

Be careful when someone:

• guarantees a migration will be simple before seeing the route estate
• dismisses SEO concerns because "Google renders JavaScript now"
• says App Router caching is easy without asking about data freshness
• treats accessibility and performance as final polish
• cannot explain how they would de‑risk launch
• wants to start coding before mapping the risk
• gives a day‑one rewrite plan for a system they have not inspected

The opposite is not nervousness. The opposite is calm specificity.

A senior developer should be able to say, "I do not know yet, but this is how I would find out." That sentence is worth more than a confident guess.

A Better Hiring Exercise

For senior Next.js work, I would not set a toy coding test. It tells you little about the real job.

Give the candidate a short scenario instead:

"We are moving a content‑heavy React site to Next.js. Organic traffic matters. Editors use a headless CMS. The current platform has 3,000 URLs, some stale redirects, and a slow build. What would you want to know before estimating the work?"

Then listen.

You are looking for the questions:

• Which URLs matter commercially?
• What must preserve search visibility?
• What does the CMS model look like?
• How does preview work?
• Which pages need fresh data?
• What build constraints already exist?
• What can be migrated in phases?
• What are the release and rollback options?
• Who owns content validation?
• How will we prove the new site is safer than the old one?

That conversation will tell you far more than a whiteboard exercise about hooks.

Wrapping up

The right senior Next.js developer is not just someone who has used Next.js. They are someone who can keep a live web platform understandable while it changes.

For replatforming, recovery, and technical SEO work, look for judgement across rendering, routing, caching, content, deployment, accessibility, performance, and team communication. Ask for evidence. Ask for trade‑offs. Ask how they would de‑risk the work before the visible build begins.

The person you want will not make the project sound magically easy. They will make the risks clearer, the first steps calmer, and the decisions easier to defend.

Key Takeaways

• A senior Next.js hiring process should test production judgement, not framework trivia.
• React skill is necessary, but serious Next.js work also needs rendering, caching, deployment, and SEO awareness.
• Portfolio work only helps when the candidate can explain ownership, trade‑offs, and outcomes.
• For recovery or migration work, ask how the developer gathers evidence before changing code.
• Cheap confidence is a worse sign than honest uncertainty paired with a clear diagnostic method.