Why We Pick Next.js For SaaS Clients

Every quarter, a new framework promises to be "the React killer." We've tried them. We come back to Next.js.

Here's why — and what we tell clients about the trade-offs.

The honest pros

Hosting is solved. Vercel deploys are 30 seconds, previews work out of the box, and the cost stays predictable for early-stage SaaS. The alternative is wrangling Docker, AWS, and your own CI/CD — months of work most clients don't need.

The hiring market knows it. When a client takes a project in-house after we ship, finding Next.js engineers is easy. That matters more than people admit.

SEO works the way you'd expect. Static rendering, sitemaps, structured data — all built in. We don't need separate tooling for marketing pages.

The honest cons

The router rewrites keep happening. Pages router → App router → who knows what's next. Every major Next version requires real migration effort.

The "edge runtime" is more limited than the marketing suggests. Most of our clients end up running their backend on Node anyway.

Vercel lock-in is real. You can self-host Next.js, but the developer experience drops sharply outside of Vercel.

What we'd pick instead

For pure backends or APIs with no UI: Fastify on Node. Faster, lighter, fewer abstractions.

For sites that need truly fast initial load with minimal JS: Astro. Underrated for marketing sites.

For mobile-first SaaS that needs native eventually: Expo + tRPC. Same TypeScript codebase, real native output.

But for 80% of what clients ask for — a SaaS dashboard with marketing pages, auth, billing, and a few API routes — Next.js is still the answer.

Building a SaaS product and stuck on stack decisions? Talk to us — we've made these calls dozens of times.