When a founder asks me what stack to build their SaaS MVP on, I default to Next.js on the frontend and NestJS on the backend more often than any other combination. Not because it's trendy — because it consistently holds up from prototype through the point where the product has real paying customers and a real engineering team.
Here's the actual reasoning, not just the recommendation.
Why Next.js on the frontend
SEO and marketing pages matter for SaaS, even though the app itself is behind a login. Next.js gives you server-rendered marketing pages, blog content, and landing pages out of the box, sitting in the same codebase as the authenticated app. You're not maintaining a separate marketing site and a separate app shell.
The App Router's server components cut down on client-side data-fetching boilerplate. For dashboard-heavy SaaS UIs, being able to fetch data on the server and stream it to the client, without a client-side useEffect + loading-state dance for every page, meaningfully reduces the amount of code that can go wrong.
It's the framework most frontend engineers already know. When it's time to hire beyond the founding team, Next.js familiarity is common enough that onboarding a new engineer takes days, not weeks.
Why NestJS on the backend
Plain Express is often the first instinct for a Node.js backend, and it works fine for a weekend project. It falls apart once a SaaS product has more than one engineer touching the backend, because Express enforces no structure — every developer organizes routes, services, and validation differently, and the codebase drifts.
NestJS gives you that structure without the ceremony of a fully enterprise framework:
- Modules force you to think about domain boundaries from day one — billing, auth, and core product logic live in separate modules, not tangled together in one
routesfolder. - Dependency injection makes services testable and swappable — I've replaced entire integrations (a payment provider, an AI provider) inside a NestJS service without touching the controllers that call it.
- Built-in validation and DTOs (via
class-validator) mean malformed requests get rejected before they reach your business logic, instead of causing a confusing failure three layers deep. - TypeScript-first — the same language and type discipline as your Next.js frontend, which matters more than it sounds like it should when a small team is moving fast across the stack.
How the two fit together in practice
The pattern I use across most SaaS builds: Next.js owns everything the user sees — marketing, auth screens, the app UI — and calls a NestJS API for anything involving business logic, data persistence, or third-party integrations (payments, AI providers, email). The two are separate deployables from day one, even in an MVP, which matters more than it seems.
Why separate deployables, even early: it keeps the backend usable by more than just the web frontend later — a mobile app, a public API, or a partner integration can all call the same NestJS service without duplicating logic into Next.js API routes. I've seen teams paint themselves into a corner by putting real business logic into Next.js API routes early on, only to need to extract it into a real backend service six months later under time pressure.
A typical MVP structure looks like this:
apps/
web/ → Next.js app (marketing + product UI)
api/ → NestJS backend (auth, billing, core domain logic)
packages/
shared-types/ → TypeScript types shared between web and api
Sharing types between the two — request/response shapes, domain models — through a shared package removes an entire category of bugs where the frontend and backend silently drift out of sync on what a payload looks like.
Where this stack takes you as you scale
The reason I keep recommending this pairing isn't just that it works for an MVP — it's that it doesn't need to be replaced when the product grows. NestJS modules can be extracted into separate services later, if a specific domain genuinely needs to scale independently. Next.js's server components and edge-rendering options give you room to optimize performance without a framework migration. PostgreSQL, sitting behind the NestJS API, handles relational data at a scale far beyond what most SaaS products ever reach.
That's the real test of an MVP stack: not whether it's the most powerful option available, but whether the team can keep building on it for the next two years without a rewrite. Next.js and NestJS, backed by PostgreSQL and deployed on AWS, has passed that test across every SaaS MVP I've built on it — from AI-powered platforms to logistics and fintech products running in production today.
