Every second founder I talk to has already decided on Next.js before they've written a single user story. Not because they evaluated it. Because a YouTube tutorial told them to.
I build SaaS products for a living, mine and my clients'. Next.js is genuinely great. But "great" and "right for your product" are not the same sentence, and conflating them is how founders end up rebuilding their frontend eight months in.
The real reason Next.js gets picked
Nobody says this out loud, so I will: most people choose Next.js because it's popular, well-documented, and Vercel markets it hard. None of that is a technical reason. It's a comfort reason.
That's not automatically wrong. Comfort and hiring pool size are legitimate factors for a solo founder or a two-person team. But they need to be named as what they are, not dressed up as an architecture decision.
Where Next.js actually earns its place in a SaaS stack
Next.js is the right call when your product needs:
- SEO-driven marketing pages sitting alongside an authenticated app (server-side rendering matters here, and it's Next.js's strongest argument)
- A single codebase for both your public site and your app shell, so you're not maintaining two frontends
- Incremental static regeneration for content that updates occasionally but doesn't need to be dynamic on every request
- A team that already knows React and needs a batteries-included framework instead of assembling routing, data fetching, and bundling by hand
If your product is a mostly authenticated, dashboard-heavy application with almost no public-facing SEO surface, a lot of what Next.js gives you goes unused. You're paying framework complexity for pages nobody will ever crawl.
Where it goes wrong
I've walked into three separate client codebases this year where Next.js was fighting the product instead of helping it.
Server Components confusion. Teams mix Server and Client Components without understanding the boundary, then wonder why state management feels broken. This isn't a Next.js bug. It's a missing mental model, and it costs weeks.
Over-fetching on every route change. Founders assume the App Router's caching "just works" for their use case. It doesn't, not for highly personalized, per-user dashboard data. You end up writing more custom cache invalidation logic than you would have with a simpler client-rendered SPA and a REST or tRPC layer.
Deployment lock-in creep. Next.js runs anywhere, technically. In practice, a lot of its more attractive features assume Vercel's infrastructure. If your architecture needs to live in your own AWS account for compliance or cost reasons, you'll spend real engineering time replicating what Vercel gives you for free.
What I actually recommend, based on the product
- Public marketing site + authenticated app, SEO matters: Next.js, App Router, hosted on Vercel or self-hosted with a Node server on AWS.
- Pure dashboard SaaS, little to no public SEO surface: Vite + React for the frontend, a plain Express or Fastify API, deployed on AWS behind your own infrastructure. Less framework overhead, more control over caching and auth.
- Heavy real-time or collaborative features: Next.js can still work, but plan your WebSocket layer as a separate service from day one. Don't try to force real-time state through server-rendered pages.
The actual decision framework
Before you touch a create-next-app command, answer three questions:
- Does more than 20% of your traffic need to be indexed by Google?
- Will your team be maintaining this for 3+ years, or shipping fast and re-architecting later anyway?
- Are you deploying to Vercel, or does compliance/cost force you onto your own AWS setup?
If the answers point away from Next.js, don't force it because it's what you know. The framework should serve the product's traffic and rendering needs, not your comfort level with the tooling.
The bottom line
Next.js isn't the wrong choice for SaaS. It's the default choice, and defaults deserve scrutiny, not blind trust. I've shipped Next.js SaaS products that were exactly right for their traffic pattern, and I've walked clients back off it when their product was better served by something simpler. The framework isn't the flex. The product working is.
Suggested internal links: Link to your Redis vs Database Caching article (Day 5) and your AWS S3 guide (Day 8) once published.
CTA: Book a free architecture review call, or DM "STACK" on Instagram for a stack audit checklist.