Can a React developer work inside an existing Next.js codebase?

Yes, if the architecture is already defined and the role is mostly UI delivery. If the engineer must own App Router decisions, caching, Route Handlers, or upgrades, prior Next.js production experience is safer.

When do we need prior App Router experience?

You need it when rendering mode, cached data, auth flow, and request handling affect product correctness. That is common in SaaS apps, dashboards, and products with server-heavy workflows.

Does a SaaS marketing site need a dedicated Next.js developer?

Usually no. Most marketing sites fit a React or general front-end profile unless the site depends on complex rendering rules, revalidation, middleware, or strict performance tuning.

Should we split the role between a React UI engineer and a Next.js platform engineer?

That can work well when the product has enough complexity to separate UI throughput from framework ownership. Smaller teams usually need one person who can handle both, which pushes the role toward a dedicated Next.js developer.

Dedicated Next.js Developer vs React Developer: What Should a SaaS Team Hire?

Key takeaways

Hire a dedicated Next.js developer when Next.js is part of the runtime, not just the UI layer.
Hire a React developer when the job is mostly client-side UI inside a stable architecture.
App Router, caching, Route Handlers, and auth create a different hiring profile from generic React work.
Multi-tenant dashboards need engineers who understand protected routes and tenant-specific data flow.
Interview for production ownership, not just component skill.

If Next.js is part of your runtime, hire a dedicated Next.js developer. If the work is mostly client-side UI inside a stable architecture, hire a React developer.

The hiring line is simple. React covers components, state, forms, and browser behavior. Next.js adds server and client boundaries, caching, request handling, deployment decisions, and framework upgrade ownership.

Boltout is a software agency.

Cost is part of this decision. The US Bureau of Labor Statistics lists a median annual wage of $133,080 for software developers and $149,990 for software developers in software publishing.

A React developer is enough when the role is mostly UI work

Hire a React developer when the engineer can succeed without owning rendering strategy, cache invalidation, Route Handlers, or framework upgrades.

That usually fits work like this:

Building reusable components and design system primitives
Managing client state, forms, charts, tables, and dashboard views
Connecting the front end to stable APIs owned elsewhere
Working inside an existing Next.js codebase with well-defined routing, auth, and deployment rules
Shipping internal tools or product areas that are mostly client-rendered

This is not a lesser hire. It is the right hire when the job is feature throughput inside a stable platform.

A marketing site usually does not need a dedicated Next.js developer

Most marketing sites can be handled by a React developer or front-end generalist. Hire a dedicated Next.js developer only when the site has enough framework complexity to become a platform surface.

A React-first profile is usually enough when the site is:

Static or lightly dynamic
CMS-driven
Updated by a small team
Light on server logic

A dedicated Next.js developer makes more sense when the site owns:

Mixed static and dynamic rendering rules across many routes
Preview workflows and content revalidation
Middleware, redirects, or custom request handling
Strict performance targets that depend on framework-level decisions

If the site is a revenue-critical acquisition surface, the real question is not which framework you use. The question is who owns rendering behavior, caching, and upgrades in production.

An App Router SaaS app usually needs a dedicated Next.js developer

If your product runs on App Router, prior Next.js production experience matters. Server Components and Client Components, framework caching, and Route Handlers change the job.

The fault lines are practical:

Server and client boundaries: Wrong placement can expose code to the browser, increase bundle size, or put data fetching in the wrong place.
Caching and revalidation: Bad cache behavior creates stale data and inconsistent product behavior.
Route Handlers and server logic: Backend logic can sit next to UI, which means the front-end owner is also making request-path decisions.
Auth and protected routes: Layouts, redirects, and session checks are part of the app structure, not a separate concern.
Framework upgrades: Someone has to review Next.js releases, test changes, and ship updates.

If the role includes those decisions, do not hire for generic React fluency and hope the rest appears on the job.

Multi-tenant dashboards push this toward dedicated Next.js experience

Multi-tenant dashboards raise the cost of mistakes, so a dedicated Next.js developer is usually the safer hire.

The risk areas are familiar:

Protected layouts and redirects: Access rules need to hold across nested routes and shared layouts.
Tenant-specific cached data: Revalidation and prefetch behavior need to match user and tenant context.
Route Handlers inside the app: Request validation, cookies, and headers can sit inside the same codebase as the UI.
Request tracing: The engineer needs to follow a request from browser to server and back without guessing.

For this kind of product, the useful interview question is not whether the candidate has built tables and forms. It is whether they have already shipped protected, stateful, server-aware flows in Next.js.

Hybrid AI products still need a Next.js owner on the web layer

If your web app handles auth, routing, streaming UI, or server-side orchestration, the front-end owner should usually be a dedicated Next.js developer.

A common split looks like this:

Next.js owns the app shell, request flow, routing, and user-facing workflows
Node.js or Python services own model calls, jobs, queues, and background work
The product crosses server and client boundaries constantly

A React developer is enough when the role is limited to UI surfaces such as chat screens, editors, upload flows, or evaluation dashboards inside an architecture your team already owns.

A dedicated Next.js developer is the better fit when the role owns request flow, streaming responses, Route Handlers, auth context, caching, and framework upgrades.

Interview for production ownership, not just React fluency

Use a scorecard that tests the production problems your app actually has.

What to test

App Router depth: Can explain shipped use of layouts, loading states, Server Components, and Client Components
Data and caching: Understands stale data failure modes and revalidation choices
Route Handlers: Has built request handlers, validation, cookies, or headers in Next.js
Auth and tenant boundaries: Can explain protected routes, redirects, and access control in production
Upgrade ownership: Can describe how they handled a framework upgrade or release review
React fundamentals: Still solid on component design, state, debugging, and performance

Screening questions

In your last Next.js app, what stayed on the server and what moved to the client?
How did you handle stale data in App Router?
What did you use Route Handlers for, and what stayed in a separate service?
How did auth work across layouts, protected routes, and redirects?
Tell me about a Next.js upgrade you owned. What broke, and how did you test it?
If a page loads the wrong tenant data after navigation, where do you look first?

The hiring rule is straightforward. If the role owns rendering, caching, auth, request handling, and upgrades, hire a dedicated Next.js developer. If the role is UI delivery inside a stable architecture, hire a React developer.

If you want a second opinion on one open role, Boltout can review the req on a short call and tell you whether it is React-shaped or Next-shaped.

Menu