"Should we use React or Next.js?" is one of the most common questions we get from technical founders. It is also slightly the wrong question.
Next.js is React. It is React with a router, a rendering model, a build system, and a set of conventions already chosen for you. So the real question is not "React or Next.js". It is "do I want to make those decisions myself, or do I want them made for me".
For most startup projects the answer is "made for me". But not all. This is the framework we use when a client asks.
What You Are Actually Choosing Between
Plain React, in practice, means React plus a build tool like Vite, plus a router you pick yourself, plus your own decisions about data fetching, code splitting, and how the app is served. It is a library. You assemble the rest of the stack around it.
Next.js is a framework. It bundles the router, the build pipeline, server-side rendering, static generation, image optimisation, and an opinionated project structure into one package. You get conventions instead of choices.
The trade is the same trade you make everywhere in engineering. Conventions buy speed and consistency. They cost flexibility and add weight. The question is whether that trade pays off for your specific product.
When Plain React Wins
Plain React, usually with Vite, is the better choice when several conditions hold.
Your product is a pure application, not a website
If you are building a dashboard, an internal tool, a data-heavy SaaS app that lives entirely behind a login, then SEO does not matter. Nobody is finding these pages on Google. Server-side rendering buys you almost nothing. A single-page React app served as static files is simpler, cheaper to host, and faster to develop against.
This is the most common case where teams reach for Next.js out of habit and regret the added complexity. A logged-in admin panel does not need server rendering.
You want full control over the stack
Some teams have strong opinions and the senior engineers to back them. They want to choose their own router, their own data layer, their own rendering strategy. Next.js conventions feel like constraints to them rather than gifts. If you have that team and those opinions, plain React respects them.
Your hosting needs to be dead simple
A static React build is just HTML, CSS, and JavaScript files. You can host it on any CDN, any static host, for almost nothing, with no server to run. Next.js can also export static sites, but its full feature set assumes a Node server or a platform built for it. If your constraint is the cheapest, simplest possible deployment, plain React has an edge.
When Next.js Wins
Next.js earns its weight when several conditions hold, and for a lot of startups they do.
You have public pages that need to rank
The moment your product has a marketing site, a blog, landing pages, or any content you want Google to find, server rendering matters. Next.js renders those pages on the server so search engines and social previews see real content, not an empty shell waiting for JavaScript. For a startup that depends on organic traffic, this is not a nice-to-have. It is the difference between ranking and not.
You want one codebase for marketing and app
A common startup shape is a public marketing site plus a logged-in product. With Next.js you can build both in one project. Marketing pages render statically. The app renders client-side behind auth. One repository, one deploy, one set of components shared across both. Splitting these into two stacks is a real cost in coordination and duplicated work.
You want sensible defaults so the team moves fast
This is the quiet reason Next.js wins most startup decisions. A new developer joining a Next.js project already knows roughly where things live, how routing works, and how pages are built. The conventions are widely known. On a plain React project, every team invents its own structure, and every new hire has to learn that bespoke setup. Conventions are onboarding speed.
You will need server-side logic close to the frontend
Next.js gives you a place to run server code right alongside your pages: API routes, server actions, server components. For a startup that does not want to stand up a separate backend on day one, this is genuinely useful. You can ship a working full-stack product from one framework, then extract a dedicated backend later if you outgrow it.
The Questions That Actually Drive the Decision
Strip away the tribalism and the choice comes down to four questions.
Question 1: Do public, indexable pages matter to this product?
If yes, lean Next.js. Server rendering for SEO and social previews is its strongest single advantage. If your product is entirely behind a login, this reason disappears and plain React becomes more attractive.
Question 2: How experienced is the team, and how opinionated?
A senior team with strong architectural opinions can wield plain React well and may find Next.js constraining. A small or mixed-experience team moves faster on Next.js conventions because fewer decisions are theirs to get wrong.
Question 3: One surface or two?
If you have both a marketing site and an app, Next.js letting you build both in one codebase is a concrete saving. If you have only an app, that advantage does not apply.
Question 4: How much does deployment simplicity matter?
If you want the cheapest, most boring possible hosting and have no server-side needs, a static React build is hard to beat. If you are fine running on a platform built for Next.js, its richer feature set is worth it.
The Honest Default
For most startup products that have any public-facing surface, Next.js is the sensible default. It removes a pile of early decisions, handles SEO out of the box, and lets a small team ship a marketing site and a product from one codebase. The conventions that feel like constraints to a senior team feel like guardrails to a startup moving fast.
Reach for plain React when the product is a pure logged-in application with no SEO needs, when you have a senior team with strong opinions, or when deployment has to be as simple as static files on a CDN.
The mistake we see most often is not picking the wrong one. It is picking Next.js for a pure internal tool and carrying server-rendering complexity that buys nothing, or picking plain React for a content-heavy product and bolting on a fragile homemade rendering setup six months later. Both are recoverable. Both are avoidable by answering the four questions honestly at the start.
What to Do Next
Write down what your product actually is. List the pages. Mark which ones a stranger should be able to find on Google. Count your team and be honest about their experience. If you have public pages and a small team, Next.js. If you have a pure app and a senior team with opinions, plain React is a clean, fast choice. The framework follows from the product, not the other way around.
Related Reading
- Next.js Project Structure That Scales - how to organise a Next.js app so it stays maintainable
- React Frontend Architecture - the architectural patterns that hold up as a frontend grows
- Frontend Development - how we build production frontends for startups and agencies