This gets argued as a framework preference and it is not one. Next.js is React with a server attached, and the question is only ever whether your application needs that server. For a large class of applications it clearly does, and for another large class it is complexity you carry without collecting anything for it. Three questions separate them, and none of them are about developer experience.
The short version
If the content must be indexed by search engines, you need server rendering. That decides it on its own.
If the app is behind a login, the SEO argument disappears entirely and the calculus changes.
Next.js buys routing, data loading and rendering conventions. A team without conventions benefits most.
The cost is a server to run and reason about, and a rendering model with more ways to be wrong.
A client-rendered app plus a prerender step covers more cases than the Next.js discourse admits.
The three questions that settle it
Answer these before reading a single feature comparison. In our experience they resolve the decision in about ten minutes, and the remaining debate is usually about taste rather than requirements.
A public marketplace, a documentation site, a content product or an e-commerce catalogue answers yes to one and needs server rendering. An internal admin tool, a dashboard behind auth, a B2B application sold by a salesperson: these answer yes to two, and the honest answer for them is usually plain React on a CDN.
If the answer to the first question is yes, the follow-up is usually how badly client rendering actually hurts, which our React SEO guide answers in more detail than this page does.
The SEO argument, stated accurately
Google will execute JavaScript and index the result. That is genuinely true and it is why the "client rendering is invisible to search" claim is out of date. It is also less reassuring than it sounds.
Rendering happens on its own schedule, with a budget, and any failure in that chain, whether a slow API, a script error or a third-party timeout, produces an indexed page containing an empty div. Server-rendered HTML has none of those failure modes because the content is in the response. For a page whose ranking is commercially load-bearing, that difference is worth the complexity. For an internal tool, it is worth nothing at all.
Where our interests differ from yours
Next.js projects are larger and more profitable for us than static React ones. We have talked clients out of Next.js more than once and it cost us revenue, which is the only reason this section is worth anything. Ask any vendor recommending a framework what they would lose if you chose the other one.
There is also a middle option that gets skipped in the framework debate: a client-rendered app with a prerender step for the handful of pages that need indexing. For a product with a marketing site and an app behind it, that is frequently the right shape, and it keeps the app deployable as static files.
Search visibility is the one requirement that settles this decision on its own, so it is worth being sure it applies before paying for it.
What you actually get
Beyond rendering, the honest case for Next.js is conventions. That sounds soft and it is the most valuable thing on the list for most teams.
"The strongest argument for Next.js is not rendering. It is that two separate teams using it will structure an application the same way, and two teams on bare React will not."
What it costs you
The second row is the one that surprises teams. Server components and client components are a genuinely good idea and they add a dimension to every question a developer asks about a piece of code. On a team that has internalised it, this is free. On a team meeting it for the first time under deadline, it is not.
A server is an operational cost as well as an engineering one, and it lands on whoever carries your backend and on call rota.
What we default to
Public content product
Next.js. The indexing requirement decides it and nothing else needs discussing.
App behind a login
React with Vite, deployed static. Faster to build, nothing to operate, no rendering model to reason about.
Both in one product
Split them. A prerendered marketing site and a static app is a simpler system than one framework doing both.
The third is the recommendation that gets the most resistance and holds up best. A marketing site and an application have different audiences, different deployment cadences and different risk profiles. Merging them into one codebase to avoid running two things usually costs more than it saves within a year.
The split recommendation is also how we scope this kind of work, described on the Node development services page.
What it costs to change your mind later
Both directions are possible and neither is free. Knowing the shape of the reversal is part of making the decision calmly, because most of the anxiety in this choice comes from treating it as permanent.
The asymmetry is the useful part. Starting on plain React and moving to Next.js when a requirement actually appears is a manageable project. Starting on Next.js and discovering you do not want to operate a server is a worse position. That argues for choosing the simpler option when the requirement is genuinely uncertain, which is the opposite of how the decision usually gets made, because the framework with more features feels like the safer default.
The third row is the one most teams have not costed. If the only reason Next.js is on the table is that three marketing pages need to rank, a prerender step gets you that for a fraction of the complexity, and the application stays a set of static files.
Migration cost is a scoping question rather than a framework one, and what React development costs covers how to size it before committing.
Questions people ask
Whichever you choose, hold it to a number: setting a performance budget covers making first paint a contract term rather than an aspiration.
Where to go next
If the choice is driven by search visibility, our React SEO guide goes deeper on what crawlers actually do with JavaScript. If it is driven by budget, what React development costs covers what really moves the number.
Yogesh Jadhav
Founder of reactdevstudio. Ten years as a working full stack developer, across SaaS products and client work.
Related, Group B only
Three more on engineering
Engineering posts only, scored within Group B, so a technical reader is never handed a procurement checklist.