Next.js Developer & Architect
I build production multi-tenant SaaS on Next.js — App Router, server components, and the right rendering strategy per route (SSR, SSG, ISR). Over 6+ years I've shipped Next.js platforms with payments, auth, and analytics that real businesses run on.
What it is
Next.js is the React framework for production: file-based routing, server and client components, built-in rendering modes (static, server-rendered, incremental), and first-class data fetching. The App Router (React Server Components) lets you render on the server by default and ship less JavaScript to the browser.
Why it matters
The rendering model is a business decision, not a detail. Static and server-rendered pages give you fast loads and clean crawlability; client components give you interactivity where it earns its weight. Choosing correctly per route is the difference between a fast SaaS and a slow one.
My experience
I use Next.js as my primary platform across a nine-product SaaS portfolio — building multi-tenant apps, payment-analytics dashboards over live PSP webhook data, and admin consoles. This very site is Next.js (App Router): server-rendered, statically generated where it counts, with per-locale routing in 10 languages.
Projects
Architecture decisions & trade-offs
Marketing/content → static (SSG); dashboards → server-rendered with caching; rarely-changing detail pages → ISR. I default to the server and only reach for client components where interactivity demands it.
Tenant resolution at the edge/middleware layer, isolation enforced in the data layer (RLS or scoped queries) — never trust the client to scope a tenant.
Fetch in server components close to where data is used; cache deliberately; stream where it improves perceived performance.
- Marking everything `"use client"` — it ships the whole tree to the browser and kills the App Router's main benefit.
- Treating SSR as free — uncached server rendering can be slower than a well-placed static page.
- Leaking tenant scope into client code instead of enforcing it server-side.
- Server components by default; client components only at the interactive leaves.
- A deliberate caching strategy per route, not accidental defaults.
- Type-safe data access and a single source of truth for tenant context.
- Measure Core Web Vitals with field data, not just lab Lighthouse.
FAQ
When should I use SSR vs SSG vs ISR in Next.js?
Use SSG for content that's the same for everyone (marketing, docs, blog), ISR for content that changes occasionally and can tolerate a short staleness window, and SSR for per-request/personalized data like dashboards. The goal is the fastest correct response for that route.
Is the App Router production-ready for SaaS?
Yes — I run multi-tenant SaaS on it. The key is using server components for data and keeping client components at the interactive edges, with tenant isolation enforced server-side.
How do you make Next.js fast?
Render on the server by default, ship minimal client JS, cache intentionally per route, self-host fonts, optimize images, and measure INP/LCP/CLS with real-user field data.
Key takeaways
- Next.js rendering choices are business decisions — pick per route.
- Server-first (App Router) + client leaves = fast, crawlable SaaS.
- Tenant isolation belongs in the data layer, never the client.