React vs Next.js. For SaaS.
When to pick Next.js as the SaaS frontend, when a standalone React SPA still wins, and the framework features (App Router, server components, streaming) that actually matter at SaaS scale.
Next.js by default. Vite when behind login.
For a new SaaS frontend in 2026, Next.js is the default choice because server rendering, built-in API routes, image optimization, and Vercel deployment together remove 2 to 4 weeks of infrastructure setup that a standalone React SPA requires. Pick Next.js when the marketing site and product share a codebase, when server-rendered personalized pages are needed, when any public-facing content benefits from SEO, or when the team will deploy to Vercel. Pick plain React with Vite when the entire product lives behind login and SEO is irrelevant (internal tools, trading apps, specialized admin dashboards), when the product is a heavy real-time SPA where server rendering adds complexity, or when backend preferences (FastAPI, Rails) conflict with Next.js conventions. The App Router (Next.js 14+, default in 2026) is the correct choice for new builds; Pages Router is fine for legacy codebases. Streaming via React Suspense meaningfully improves perceived performance on data-heavy dashboards.
React is the renderer. Next.js is everything else.
React is a library for building UI components. It does not have routing, server rendering, API handling, image optimization, deployment conventions, or data fetching built in. To ship a real app with React, you bolt on React Router for navigation, a build tool (Vite, Create React App, Webpack) for compilation, a data layer (TanStack Query, Apollo, SWR) for API calls, and a hosting solution. Each is a good choice individually; together they are the bring-your-own-everything model.
Next.js is a React framework that bundles the common picks. File-system routing replaces React Router. Server-side rendering and static generation are built in. API routes (or the newer Route Handlers) replace a separate backend for simple APIs. Image optimization via next/image, font optimization via next/font, middleware, internationalization, analytics integration - all built in. The opinionation is the feature; Next.js removes decisions so you can ship faster.
The tradeoff: Next.js couples your frontend to its conventions. If you want to mix in a different router, different image solution, different build tool, you fight the framework. For most SaaS teams this is net positive - the conventions are sensible and the time saved compounds. For teams with specific tooling preferences or architectural constraints (an existing Rails monolith that should stay the source of truth), plain React avoids the coupling.
Four scenarios, clear wins.
Scenario one: the marketing site and the product share a codebase. A single Next.js project can serve /blog, /pricing, /docs as public SSR pages that Google indexes, and /app, /dashboard as authenticated product routes. One codebase, one deploy, one design system. Most 2024-2026 successful SaaS launches use this pattern because it eliminates the coordination cost of keeping marketing site and product visually aligned.
Scenario two: personalized server-rendered pages. A product dashboard that needs to render with the user's data populated before sending HTML (for fast perceived load, for SEO-friendly personalized pages, or for compliance with user-specific auth rules) is Next.js's sweet spot. Server Components in the App Router handle this natively - the server fetches user data, renders the HTML, sends to client; no loading spinners on initial load.
Scenario three: public-facing shareable content. SaaS products that generate public URLs (shared dashboards on Linear, public Notion pages, public Figma files) benefit from Next.js's static generation and ISR for those pages - they are cached at the edge, load in under 500ms globally, and Google indexes them. Scenario four: the team deploys to Vercel. Vercel is built for Next.js; git-push deploys, preview URLs per pull request, edge middleware, image optimization all work out of the box. Saving 2 to 4 weeks of infrastructure work is the concrete value.
Vite + React Router for the right cases.
Case one: entire product lives behind login, SEO is irrelevant. Internal tools, B2B admin dashboards, trading apps, monitoring dashboards. Server-side rendering on the homepage does not help when the homepage redirects to /login which redirects to /app. The SSR overhead is pure cost. Vite plus React Router plus a separate backend is cleaner.
Case two: heavy real-time SPA. Products where the entire app is a single-page experience with complex client-side state - collaborative editors (Figma, Linear, Miro), drawing tools, specialized editors, trading interfaces. These apps live in the browser; Next.js server rendering does not help because the app is fundamentally client-side. Plain React with sophisticated state management (Zustand, Jotai, Redux Toolkit) serves these patterns better than Next.js.
Case three: non-Node.js backend preference. If the backend is FastAPI, Ruby on Rails, Django, or Go, forcing the frontend into Next.js conventions fights the backend. Plain React frontend plus dedicated backend communicates via REST or GraphQL APIs; both sides stay clean. This split is common in enterprise SaaS where the backend is already established and the frontend is being modernized.
New mental model, smaller bundles.
Next.js App Router (stable since Next.js 13, default in 14 and 15) is built on React Server Components. Components marked as Server Components run only on the server; they can fetch data directly from a database, use secret API keys, and do not ship JavaScript to the client. Components marked as Client Components (via the 'use client' directive) are traditional React that runs in the browser. The pattern: data-fetching and static rendering in Server Components, interactivity in Client Components.
The benefit: smaller client-side JavaScript bundles. A dashboard page that fetches and renders data in a Server Component ships 30 to 60 percent less JavaScript to the browser than the equivalent built with client-side fetching. On slow connections and low-powered devices, this shows up as measurably faster perceived load times. For SaaS products serving users on mobile or in connectivity-constrained regions, the difference is material.
The cost: learning curve. Server Components are a new mental model that mixes server and client code in the same file; forgetting which is which causes bugs. The error messages in Next.js 14 and 15 have improved a lot, but the initial ramp-up for a new engineer is 2 to 4 weeks to feel fluent with the pattern. For teams building greenfield SaaS in 2026, the investment pays off. For teams maintaining existing Next.js apps on the Pages Router, incremental migration is an option - Pages Router is still supported and likely will be for years.
Excellent default, cost at scale.
Vercel is built by the company that builds Next.js. The integration is tight: git-push-triggered deploys, preview URLs per pull request that team members can share, edge middleware that runs globally under 50ms, zero-config image optimization, ISR for revalidation-on-demand, analytics integration. For a small SaaS team, Vercel saves real infrastructure work - 2 to 4 weeks of setup for Kubernetes, AWS, or equivalent.
The cost surprises some teams. Vercel's free tier is generous (100GB bandwidth per month), but paid tiers scale with usage. A high-traffic marketing site (1M monthly visits) can cost 200 to 500 dollars per month on Vercel. A product app with heavy server rendering and ISR can hit 1,000 to 5,000 dollars per month at 10M-plus monthly active users. For SaaS between 1M and 50M annual revenue, Vercel costs are a rounding error; at higher scale, self-hosting Next.js on AWS or Cloudflare Workers becomes attractive.
Lock-in is soft but real. Next.js runs outside Vercel - SST on AWS, Cloudflare Workers via the OpenNext project, self-hosted Node.js on Railway or Fly.io, AWS Amplify. The experience is less polished and certain features (image optimization, ISR) require additional configuration. For SaaS starting fresh in 2026, Vercel is the right default; knowing the exit path exists is the insurance. Related reading: SaaS MVP in 90 days, SaaS pricing page design, SaaS onboarding metrics.
Six answers.
What is the difference between React and Next.js?
React is a JavaScript library for building user interfaces; Next.js is a full framework built on React that adds server-side rendering, routing, API routes, image optimization, and deployment infrastructure. A plain React SPA (single-page app) built with Vite or Create React App handles rendering in the browser only; Next.js renders pages on the server, sends pre-rendered HTML to the client, then hydrates with React for interactivity. In 2026, Next.js is the default choice for new SaaS frontends because the server-side rendering, built-in API routes, and Vercel deploy path together remove weeks of infrastructure work. Plain React remains the better choice for app-shell-heavy products where SEO does not matter and the entire UI lives behind authentication.
When should I pick Next.js for a SaaS?
Four cases where Next.js is clearly the right call. One, the marketing site and the product share a codebase - Next.js handles the SEO-optimized public pages and the authenticated product app in one Next.js project. Two, server-side data fetching with authentication needs to happen before the page renders (the user-specific dashboard, the personalized product page). Three, the product has a public-facing read-only layer (case studies, public dashboards, shareable links) that benefits from Google indexing. Four, the team already uses Vercel or plans to, and wants zero-config deploys. Below these cases, plain React SPA is simpler and serves the same goals at lower complexity.
When should I still pick plain React (Vite) over Next.js?
Three cases. One, the entire product lives behind a login screen and SEO is irrelevant (internal tools, B2B admin dashboards, trading apps). Two, the product is a single-page app with heavy client-side state (real-time collaboration, complex drawing tools, specialized editors) where Next.js server-rendering adds complexity without benefit. Three, the team has strong preferences for specific build tooling (Vite, Turbopack standalone, esbuild) or backend frameworks (FastAPI, Ruby on Rails as the API plus React as the frontend) that conflict with Next.js conventions. In these cases, Vite plus React Router plus a separate backend delivers equivalent results with less framework-specific learning.
What is the App Router in Next.js and should I use it?
The App Router (stable since Next.js 13, default in Next.js 14 and 15) replaces the older Pages Router with a file-system routing system based on React Server Components. Server Components render on the server and do not ship JavaScript to the client; Client Components are traditional React rendered in the browser. The App Router is the default for new Next.js projects in 2026 and should be the choice for any new SaaS build. Legacy codebases on the Pages Router can migrate incrementally or stay on Pages Router - both are supported. The benefit of App Router is smaller client-side bundles for data-heavy pages (the server does more work, the browser ships less JavaScript); the learning curve is steeper because Server Components are a new mental model.
What is streaming and why does it matter for SaaS?
Streaming (React Suspense with streaming) means the server sends HTML to the browser as it becomes available, rather than waiting for the entire page to finish rendering. For a SaaS dashboard with multiple data sources (user info, recent orders, analytics charts, notifications), streaming lets the fast-loading parts (page shell, user info) appear while the slower parts (analytics) still load. Perceived performance improves meaningfully on data-heavy pages. Practical impact: typical dashboard TTFB (time to first byte) goes from 1500 to 300 milliseconds for the shell, with data filling in over the next 1 to 2 seconds. Users see the app load fast even when underlying queries are slow. The pattern is available in Next.js App Router out of the box.
How does the Vercel deployment story affect the choice?
Vercel is the primary deployment platform for Next.js and is built by the same company. Deploy is git-push-triggered; preview URLs spin up per pull request; edge middleware runs globally; image optimization and ISR (incremental static regeneration) work without configuration. For a small SaaS team, Vercel saves 2 to 4 weeks of infrastructure work that would otherwise go into Kubernetes or AWS setup. The tradeoff is vendor lock-in (Next.js runs outside Vercel via Cloudflare Workers, AWS Amplify, or self-hosted Node.js, but the experience is less polished) and cost - Vercel can get expensive at scale, especially for high-traffic marketing sites (100 to 5000+ dollars per month based on usage). For SaaS at 1M to 50M in revenue, Vercel is usually the right default; at higher scale, self-hosting becomes attractive.
Frameworks are team fit.
Our SaaS engagements cover Next.js greenfield builds, plain React + Vite when the shape fits, and Pages Router to App Router migrations. Scoped quote in 48 hours.