The new default: server first, client when needed
With Next.js 15, React Server Components are the default. That single decision rewires how you fetch data, ship JavaScript and structure pages. Done right, you ship dashboards that feel instant and weigh a fraction of their predecessors. Done wrong, you build a hybrid mess.
What RSC actually buys you on a SaaS
- Smaller bundles. Server components never reach the browser as JS, only as HTML. On a typical admin dashboard we cut the initial JS payload by 60-70%.
- Data fetching where data lives. No more
useEffect+fetchwaterfalls. The component reads from Postgres directly. - Better SEO out of the box. Pages render fully on the server with no extra config — a big deal for SaaS marketing pages that share the same codebase.
When to still pick a client component
- Anything interactive — forms, drag-and-drop, charts that respond to hover.
- Anything that needs browser APIs — webcam, geolocation, local storage.
- Anything that streams from a third-party SDK in the browser (Stripe Elements, Mapbox).
A common SaaS layout
app/
(marketing)/page.tsx -- server component, fully cached
(app)/dashboard/page.tsx -- server component, per-request fetch
(app)/dashboard/_chart.tsx -- "use client" island for the chart
(app)/settings/form.tsx -- "use client" for form interactivityGotchas we hit in production
- Auth in server components is different. Read cookies via
headers(), never via a client hook. - Caching is aggressive. Use
revalidatePathandrevalidateTagdeliberately — a stale dashboard is worse than a slow one. - Database connections. Pool them properly; server components are short-lived but called constantly.
Should you rewrite your existing SaaS?
Usually no. Migrate when you are touching a feature anyway. Greenfield SaaS in 2026, however — RSC by default, and you will thank yourself by month three.
Planning a Next.js 15 SaaS or modernising an older React stack? Book a discovery call.