Every few weeks a founder tells us, "we want to build the frontend in React," and when we ask a follow-up question — plain React or Next.js? — we get a pause. It's a fair pause. The two get talked about almost interchangeably online, but they answer different questions, and picking the wrong one quietly costs teams months later in the form of bolted-on routing libraries, SEO workarounds, or server infrastructure nobody planned for.
We've shipped production apps in both, so this isn't a theoretical comparison. Here's how we actually think about it when a client asks.
What React actually is
React is a UI library. It gives you components, state, and a rendering model — and that's genuinely it. Routing, data fetching, server rendering, image optimization, and build configuration are all decisions you or your team have to make separately, usually by picking a bundler like Vite and adding libraries like React Router and React Query on top.
That sounds like more work, and it is, but it also means more control. If you're building an internal admin dashboard, a highly interactive tool behind a login wall, or a product where search engines will never see the content anyway, a lean React single-page app avoids a lot of framework overhead you don't need.
What Next.js adds on top
Next.js is an opinionated framework built on React. It gives you file-based routing, server-side rendering and static generation, built-in image and font optimization, API routes, and a deployment story that most hosting providers understand well. In exchange, you follow its conventions.
The part that matters most for most businesses is rendering. Next.js can render a page on the server and send fully-formed HTML to the browser (and to search engine and AI crawlers) on the first request. A plain React SPA, by contrast, ships a mostly empty HTML shell and builds the page in the browser with JavaScript — which works fine for logged-in users, but is a real handicap if you need the page to rank on Google or show up correctly when an AI assistant summarizes it.
Where this actually changes the decision
In our own web development projects, the split usually comes down to one question: does this page need to be found?
- Public marketing sites, blogs, product pages, service pages — these live or die by search visibility, so we default to Next.js (or a similarly SSR-capable framework like Nuxt, if the team prefers Vue). This is exactly why this website you're reading is not a plain SPA.
- Internal dashboards, admin panels, authenticated SaaS tools — nobody needs Google to index a login-gated inventory dashboard. A plain React app with client-side routing is often lighter, simpler to reason about, and cheaper to host, since it can ship as static files behind a CDN.
- Hybrid products — a public marketing site plus a logged-in app — sometimes justify two separate codebases: a Next.js site for the public pages, and a React SPA for the authenticated product. This is more common than people expect once a startup has both a landing page and a real product to maintain.
Performance and cost, honestly
Next.js is not automatically faster. Server rendering adds a server-side compute step, which means either a Node.js server running somewhere or a serverless platform billing you per request. A static React SPA served from a CDN can be extremely cheap and fast for content that doesn't change per-user.
Where Next.js earns its keep is largest contentful paint and perceived speed for first-time visitors, plus far simpler SEO metadata handling — canonical tags, Open Graph data, structured data — all of which we cover in detail when we audit a client's existing site. If your traffic is mostly first-time organic visitors landing from Google or an AI search result, that first impression matters more than raw client-side interactivity speed.
Our honest recommendation
If you're not sure yet, and the project has any public-facing content that needs to rank, start with Next.js. The cost of the extra framework conventions is small, and undoing an SEO-blind SPA later is expensive. If you're building a purely internal tool or a product experience that lives entirely behind authentication, don't pay the SSR tax — a plain React app will serve you well and stay simpler to maintain.
Either way, the framework is rarely the actual bottleneck in a project. Clear data models, sensible component architecture and a team that tests before shipping matter more than which acronym is on the tin. If you want a second opinion on your specific situation, our team is happy to look at what you're building and tell you plainly which approach fits — no framework tribalism involved.