If you're scoping a new SaaS product, "React or Next.js?" usually shows up in the first planning call — right after pricing and before the database. It's a fair question, and it's also a slightly wrong one, because React and Next.js aren't sitting on opposite sides of a scale. Next.js is built on top of React. The real decision is whether your SaaS needs what Next.js adds — server rendering, file-based routing, built-in API handling, image and font optimization — or whether a plain React SPA behind a separate backend keeps things simpler and cheaper to run.
I've shipped both across dozens of client projects, from marketing-heavy SaaS landing pages that live or die on SEO to internal dashboards that never touch a search engine. Here's the breakdown I actually use when a client asks.
Choose React (SPA)
Your product sits entirely behind a login — dashboards, internal tools, admin panels — and you already have or want a separate API. SEO isn't a ranking factor because nothing is public.
Choose Next.js
Your SaaS has public, indexable surfaces — marketing pages, blog, pricing, docs — sitting alongside the app itself, and you want one codebase, one deploy, and server-rendered pages that load fast and rank.
01 What you're actually comparing
React is a UI library. It renders components in the browser and gets out of the way — routing, data fetching, server rendering, and build tooling are all decisions you make yourself, usually by wiring up React Router, a bundler, and a backend framework of your choice.
Next.js is an application framework that wraps React with conventions: file-based routing, server-side rendering and static generation out of the box, API routes living in the same project, and a build pipeline that's already tuned for production. You give up some flexibility in exchange for not having to make (or maintain) a dozen infrastructure decisions.
For a SaaS specifically, this trade-off shows up in three places: how your public pages get indexed, how your app's first load performs, and how much backend you have to stand up separately.
02 Side-by-side, where it matters for SaaS
02 When plain React is genuinely the right call
Not every SaaS needs Next.js, and adding it when you don't need it just means carrying a heavier framework for no benefit. React alone tends to be the better foundation when:
- The product is fully gated. If every route sits behind authentication — think Notion-style workspace apps, analytics dashboards, internal ops tools — there's nothing for Google to index anyway, so SSR buys you very little.
- You already have a backend team or framework. If your API is Laravel, Django, or a dedicated Node service that your backend engineers own, bolting Next.js's API routes on top is redundant. A React SPA talking to that API over REST or GraphQL is a cleaner split of responsibilities.
- You want the simplest possible hosting story. A React SPA builds down to static files. It can sit on any CDN, with no Node server to keep alive, patch, or scale.
- Your team is small and wants fewer moving parts. React with Vite, a router, and a data-fetching library like TanStack Query is a smaller surface area to learn than the full Next.js App Router, server components, and caching model.
03 When Next.js pays for itself
Most SaaS products aren't fully gated, though. There's almost always a public layer — a homepage, pricing, a blog for organic traffic, docs, maybe a status page — sitting in front of the actual app. Next.js starts winning as soon as that public layer matters commercially:
- Organic acquisition is part of the growth plan. If pricing, feature, and comparison pages need to rank, server-rendered HTML that search engines can read immediately is a real advantage over a client-rendered shell.
- You want one codebase for marketing and app. Next.js lets the public site and the logged-in product share components, a design system, and a single deploy pipeline, instead of running two separate projects.
- Performance on first load is a selling point. Server-rendered pages typically show meaningful content sooner, which matters for conversion on pricing and landing pages even if it matters less inside the authenticated app.
- You're fine with a Node runtime. Full SSR needs a server process, not just static hosting. If you're already comfortable with Vercel or running Node in production, this isn't a real cost.
Common pattern I build for clients: Next.js for the marketing site, docs, and blog (where SEO is the whole point), with the authenticated app either living in the same Next.js project as client-rendered routes, or split into a separate React SPA if the app is complex enough to want its own build and deploy cycle.
04 A minimal example of the split
Here's roughly how the routing conventions differ for a SaaS with a public pricing page and a private dashboard.
05 Migrating later isn't as painful as it sounds
A question I get often: "If we start with React and outgrow it, is switching to Next.js a rewrite?" Mostly, no. Since Next.js is React underneath, your components, hooks, and state management largely carry over. What changes is routing, data fetching, and how pages are rendered. Teams usually migrate incrementally — standing up Next.js for the marketing site first while the existing React app keeps running, then folding the app in once the public side is stable.
Going the other direction — starting on Next.js and later deciding you only need a SPA — is rarer, since Next.js can render everything client-side if you choose to, so there's usually no need to leave.
06 Frequently asked questions
Is Next.js just React with extra steps?
Not extra steps so much as extra conventions. Next.js still uses React components and hooks; it adds routing, rendering strategy, and build tooling on top so you don't have to assemble them yourself. The trade is less flexibility for less setup.
Does a SaaS dashboard need server-side rendering?
Usually not. If the dashboard sits behind a login and isn't indexed by search engines, client-side rendering with React is typically fine and simpler to reason about than mixing rendering strategies for pages nobody but logged-in users will see.
Can I use Next.js for the app and a separate backend at the same time?
Yes. Next.js API routes are optional. Many SaaS builds use Next.js purely for the frontend and rendering, while a separate Laravel, Node, or Django service handles the actual application logic and database access.
Is React cheaper to host than Next.js?
Generally yes for a pure SPA, since it compiles to static files servable from any CDN. Next.js with server rendering needs a running Node process, which typically costs more than static hosting, though the difference is often small at typical SaaS traffic levels.
What do most SaaS products actually use?
A common pattern is Next.js for the public marketing site, blog, and docs where SEO matters, paired with a React single-page app (or client-rendered Next.js routes) for the authenticated product itself.