It's not really React vs Next.js
Next.js is a framework built on React — routing, rendering strategy, bundling and a server runtime, decided for you so you're not assembling them from separate packages. Plain React (via Vite, typically, these days) gives you the library and leaves those decisions to you. The real question is whether you want those decisions made by a framework or made by hand.
When I reach for Next.js
- The page needs to be found by search — a marketing site, a services page, anything where SEO is a real requirement rather than an afterthought. Server rendering isn't optional there; it's the whole point.
- The product needs a mix of public, indexable pages and authenticated, dynamic ones in the same codebase — App Router handles both without two separate apps.
- Time-to-first-byte and Core Web Vitals are part of the brief, not just "the site should feel fast." Next.js's rendering options (static, streaming, incremental) give real levers to pull.
- The team wants conventions decided for them — file-based routing, a standard data-fetching pattern — so a new engineer is productive in a day, not a week.
When plain React is the better answer
A pure internal dashboard behind a login, with no public pages and no SEO requirement at all, often doesn't need a meta-framework's rendering machinery — a Vite-based React SPA can be simpler to reason about and faster to iterate on, because there's no server-rendering boundary to think about for every component.
The same applies to an embeddable widget, a component meant to be dropped into someone else's page, or a build where the team already owns a bespoke server and doesn't want Next.js's server runtime alongside it. "We might need SEO later" is not, by itself, a reason — that's a real conversation to have honestly, not a default to reach for out of caution.
The questions I actually ask on a discovery call
- Does any part of this need to rank in search or be shared with a rich preview? If yes, that alone usually settles it.
- Is there a mix of public and authenticated surfaces, or is it one or the other?
- Who maintains this after handover — a team that wants strong conventions, or one confident enough to make its own architectural calls?
- What does "fast" mean here — first paint on a marketing page, or interaction latency inside an app that's already loaded?
None of these questions have a universally correct answer. They have an answer for this specific project, and that's the one that decides the stack — not a default, and not what was used last time.