Next.js vs React: Which Should You Build On?

TL;DR: React is a UI library — it builds components. Next.js is a full framework built on top of React — it adds routing, server-side rendering, static generation, image optimisation, and SEO features. For most startups building a public-facing product or marketing site, Next.js is the better starting point. For complex SPAs with no SEO requirements, plain React is fine.

This is one of the most common questions founders ask when they're scoping out their first build. And it's the right question to ask early — because switching later is painful.

The short answer is nuanced. Let's break it down properly.

---

First: Understand What React Actually Is#

React is not a framework. It's a JavaScript library for building user interfaces. It handles one thing really well: rendering components based on state.

It does not come with:

• A router (you add React Router separately)
• A way to handle server-side rendering
• Image optimisation
• API routes
• A build system with performance defaults

React is a blank canvas. Powerful, but deliberately minimal.

---

What Next.js Adds on Top of React#

Next.js is a React framework built and maintained by Vercel. It wraps React and adds a production-grade layer on top of it:

Next.js is essentially React with a lot of sensible defaults already made for you.

---

The SEO Argument (It's a Big One)#

This is where the decision often becomes clear for startups.

Plain React apps are client-side rendered (CSR) by default. When Google's bot crawls your page, it initially receives an empty HTML file with a <div id="root"> and a JavaScript bundle. The actual content — headings, body text, meta descriptions — only exists after the JavaScript executes.

Google can render JavaScript, but:

• It's slower and less reliable than reading static HTML
• There's often a delay of days or weeks between initial crawl and JS rendering
• Important content can be missed, especially on complex apps

The result: your pages don't rank well, and your Core Web Vitals suffer.

Next.js solves this completely. With Static Site Generation (SSG), your pages are pre-built as full HTML files at deploy time. Googlebot reads your full content immediately, on first crawl. No rendering delay, no empty HTML.

For any startup that cares about organic search — and most should — this alone makes Next.js the default choice.

---

Rendering Modes: Understanding Your Options#

Next.js gives you three main rendering strategies (four if you count the App Router's React Server Components):

Static Site Generation (SSG)#

Pages are built at deploy time and served as static HTML. Best for:

• Marketing pages (homepage, features, pricing, about)
• Blog posts
• Documentation
• Landing pages

// pages/about.js
export async function getStaticProps() {
  const data = await fetchData();
  return { props: { data } };
}

This is the fastest option. Pages are served from a CDN with zero server processing time.

Server-Side Rendering (SSR)#

Pages are rendered on the server on each request. Best for:

• Pages with data that changes frequently
• User-specific pages (if they must be server-rendered)
• Pages that depend on request data (cookies, headers)

// pages/dashboard.js
export async function getServerSideProps(context) {
  const data = await fetchUserData(context.req.cookies.userId);
  return { props: { data } };
}

Slower than SSG but still much faster and more SEO-friendly than CSR.

Incremental Static Regeneration (ISR)#

The best of both worlds — pages are statically generated but can be revalidated in the background at a set interval:

export async function getStaticProps() {
  const data = await fetchData();
  return { props: { data }, revalidate: 60 }; // Regenerate every 60 seconds
}

Great for blog posts, product pages, and anything that needs fresh content without full server-side rendering.

Client-Side Rendering (CSR)#

You can still do plain client-side rendering in Next.js using useEffect + fetch — just like in plain React. This is appropriate for authenticated dashboards, user settings, and any content that shouldn't be indexed.

---

When Plain React Is the Right Choice#

Let's be balanced. Next.js is not always the answer.

Use plain React (Create React App or Vite) when:

• You're building a single-page app with no public-facing pages — think an internal dashboard, admin tool, or authenticated SaaS app with no marketing site
• SEO is irrelevant — your users log in before seeing any content
• You need maximum flexibility and don't want framework conventions
• Your team is already experienced with a specific React setup and the migration cost outweighs the benefits
• You're building a quick prototype or MVP to validate an idea before investing in architecture

For an internal tool used by a fixed set of users who will log in directly, Next.js's SSR/SSG machinery is largely irrelevant overhead.

---

When Next.js Is Clearly the Right Choice#

Use Next.js when:

• You have a public marketing site that needs to rank in Google
• You're building a blog, documentation site, or content-heavy product
• You care about Core Web Vitals and page speed (and you should)
• You need API routes and want to keep your backend in the same codebase
• You're deploying on Vercel (they built Next.js — the integration is seamless)
• You're building something with mixed content — some public pages, some private app pages

Most SaaS startups fall squarely in this category. Your marketing site (homepage, pricing, features, blog) needs to rank. Your app dashboard can be client-side rendered behind a login.

---

Performance Comparison: Real Numbers#

Let's talk Lighthouse scores for a typical startup marketing page:

These numbers are illustrative of real-world patterns I've seen on client projects at dipanshudev.com/projects. SSG with a CDN is in a different league.

---

The Developer Experience#

Both React and Next.js are excellent to work with, but they have different developer experience characteristics.

React (plain) gives you maximum freedom. You choose your router, your data fetching library, your CSS solution. This is powerful for experienced teams. For early-stage startups, it can lead to inconsistent architecture and decision fatigue.

Next.js makes many of those decisions for you. File-based routing, built-in API routes, structured rendering modes. This reduces bikeshedding and keeps teams aligned. The App Router (introduced in Next.js 13) is particularly powerful, though it has a steeper learning curve.

Next.js's ecosystem around Vercel is hard to beat for DX:

• Zero-config deployment
• Preview URLs for every PR
• Built-in analytics and performance monitoring
• Edge functions for low-latency API responses

---

Deployment Considerations#

Plain React apps are easier to deploy anywhere as static files. Next.js with SSR needs a Node.js environment or a platform that supports serverless functions for the server-rendering layer.

For most startups, Vercel + Next.js is the fastest path from code to production.

---

Making the Decision: A Framework#

Ask yourself these four questions:

1. Will any pages be publicly accessible without login? — If yes, Next.js.
2. Do you care about Google rankings for any part of your product? — If yes, Next.js.
3. Is this purely a logged-in SaaS app with no public content? — Plain React is fine.
4. Do you want to deploy in under an hour with a great developer experience? — Next.js + Vercel.

The vast majority of startups building in 2025 will land on Next.js. It's the safer, more capable, and more SEO-friendly default. Starting with plain React and migrating later adds real cost and complexity.

---

My Recommendation#

For a new startup, default to Next.js unless you have a specific reason not to.

The overhead of learning Next.js conventions is minimal. The gains — automatic code splitting, SSG/SSR, image optimisation, built-in API routes, better SEO, faster performance — are substantial.

If you're unsure which architecture fits your specific product, reach out at dipanshudev.com — this is exactly the kind of scoping work I do before a single line of code gets written.

---

FAQ#

Q: Is Next.js harder to learn than React? A: Next.js has a learning curve if you're new to server-side rendering concepts. But if you already know React, picking up Next.js is relatively fast. Most developers become productive with Next.js within a week. The file-based routing and data fetching patterns are well-documented.

Q: Can I use React libraries with Next.js? A: Yes — Next.js is built on React, so virtually every React library works with it. The only exception is libraries that rely on browser-only APIs (like window or document) in components that get server-rendered. This is a fixable issue with dynamic imports and useEffect.

Q: Is Next.js good for e-commerce? A: Yes, very good. Shopify Hydrogen is built on React but many independent stores use Next.js with headless commerce (Medusa, Commerce.js, or direct Shopify Storefront API). SSG with ISR is perfect for product pages that need to be fast and SEO-optimised.

Q: Does Next.js work with Supabase? A: Perfectly. Supabase + Next.js is one of the most popular stacks for modern SaaS products. Supabase handles auth, database, and storage. Next.js handles the frontend and server-side rendering. The official Supabase SSR package is designed specifically for Next.js.

Q: What is the Next.js App Router vs Pages Router? A: The Pages Router is the original Next.js routing system (files in /pages). The App Router (Next.js 13+, stable in 14) is the newer system (files in /app) based on React Server Components. The App Router is more powerful and is the recommended approach for new projects, but the Pages Router is still fully supported.

---