Next.js vs Plain React: Which Should Your Web App Use?
Next.js or plain React? It's one of the first questions on a new web project, and the wrong call costs you in SEO, speed, and rework later. Here's a founder-friendly breakdown of when each one is the right choice.
Shayan Jamil·June 8, 2026·5 min read
"Should we use Next.js or just React?" comes up on almost every new web project, usually from a founder who's heard both names and wants to make sure the decision isn't made carelessly. It's a good instinct, because this choice quietly shapes how your product performs in search, how fast it loads, and how much rework you might face later.
The short version: they're not really competitors. Next.js is built on top of React. But the decision still matters, and picking based on your actual goals — not on what's trendy — saves real money. Here's how I think about it.
What each one actually is, in plain terms
React is a library for building user interfaces. On its own, it ships a web app that runs entirely in the browser: the user's device downloads the code and then builds the page. That's great for app-like products people log into, but it gives search engines and social previews an empty page to start with.
Next.js is a full framework around React. It adds the things most real products need anyway: rendering pages on the server (so they arrive fast and fully formed), built-in routing, image optimization, and a place to put backend logic. You're still writing React — Next.js just handles the heavy lifting around it.
The business question: where does it actually matter?
The decision usually comes down to one thing: who needs to see your content, and how fast?
If your product is a public-facing site — a marketing site, an e-commerce store, a blog, a directory — then SEO and load speed are revenue. Search engines and social platforms need real HTML to read and rank, and every extra second of load time costs you visitors. This is exactly where Next.js earns its place, and it's why I reach for it on content-heavy and customer-facing builds.
If your product is a private, app-like dashboard that users log into — an internal tool, an admin panel, a member portal — then SEO barely matters, because the valuable pages are behind a login anyway. Plain React (or a lighter setup) can be perfectly fine here.
The quick rule I use
If strangers need to find it through Google or see a nice preview when it's shared, lean Next.js. If it lives entirely behind a login and nobody's searching for it, plain React is often enough. Most real products have some of both — and Next.js handles both comfortably, which is why it's my default.
Why this affects your timeline and budget
Choosing wrong isn't fatal, but it's expensive in a specific way. The classic mistake is building a marketing-facing product as a plain React app, launching, and then discovering pages don't rank and link previews show up blank. Retrofitting server rendering later means reworking the foundation — paying twice for something that could have been right from day one.
Going the other way is cheaper to recover from but still wasteful: pulling in a full framework for a tiny internal tool that three people use adds complexity nobody needed.
A realistic example
On my projects, the Convertible M&T storefront is a good case for Next.js: it's an e-commerce platform where customers browse parts, search the catalog, and need to find products through search engines — so server rendering and speed directly support sales. Skalable, a finance marketing site, is similar: it has to load fast and present well when shared, which is squarely Next.js territory.
By contrast, the admin dashboards behind several of those products live entirely behind a login. There, the priority is a fast, responsive interface for the team — not search ranking — so the trade-offs look completely different. The point isn't that one tool is "better"; it's matching the tool to who the page is for.
Common mistakes founders make here
- Picking based on hype instead of whether the pages need to be found in search.
- Building a public, content-heavy product as a browser-only app, then paying to retrofit SEO after launch.
- Over-engineering an internal tool with a full framework it doesn't need.
- Ignoring load speed — slow public pages quietly lose you visitors and search ranking.
- Treating the framework as the whole decision, when the data model and clean backend APIs matter just as much for how the product grows.
How I approach the choice on a new project
- Start with who the pages are for. Public and searchable, or private and behind a login?
- Weigh SEO and load speed against the cost of added complexity.
- Default to Next.js for anything customer-facing, because it handles both the public and the app-like parts of a product cleanly.
- Keep it simple where simplicity wins — not every internal tool needs the full toolbox.
- Decide once, early, so the foundation doesn't need rebuilding when traffic shows up.
Most of the time, for a real product that mixes public pages and logged-in features, Next.js is the pragmatic default. But I make the call based on your goals, not a preference — and I'll happily talk you out of complexity you don't need.
Not sure which fits your project?
If you're planning a web app and want a straight answer on the right setup — one that fits your goals, your budget, and how you expect to grow — that's the kind of decision I help founders make before a line of code is written.
Take a look at my projects, read a little about how I work, and get in touch with what you're building. I'll tell you honestly what I'd use and why.