Why we still pick Next.js over Astro for most SaaS in 2026

Next.js is a full-stack React framework that renders pages, handles routing, and runs server logic in one process. Astro is a content-first site builder that ships near-zero JavaScript by default and hydrates only the islands that actually need interactivity. The 2026 question for a SaaS team is not which framework is better in the abstract. It is which one fits the shape of the product you are building.

Most SaaS products have an authenticated app at their core. A dashboard, a settings panel, a workspace, a billing portal. Those screens read and write user data on every navigation, hold state across components, and depend on session cookies the server has to verify on each request. Next.js was designed for that shape. Astro can do a surprising amount of it through server islands, server actions, and the Sessions API, but the closer you get to a real product surface, the more you reach for libraries to fill in what the framework does not own. We have shipped both this year. For a SaaS specifically, Next.js stays our default.

TL;DR

Pick Next.js when the site is the product. Pick Astro when the site is content around the product. If you have a single codebase and that codebase has to host signup, login, dashboards, and billing, Next.js fits. If you have a separate marketing site that is mostly pages, posts, docs, and pricing, Astro is faster and cheaper to operate. The gap is widening in both directions: Next.js holds the dominant share of new enterprise React projects in 2026, and Astro was acquired by Cloudflare in January 2026, signalling a serious bet on islands architecture for content (Alex Bobes, 2026).

Where Next.js wins for SaaS

One repo for the app and its API

Next.js 16 ships Turbopack as the default bundler for both next dev and next build, and the React Compiler is stable in production (Vercel, 2026). The framework owns rendering, routing, server actions, route handlers, middleware, and edge functions inside one project. For a SaaS this matters because the same git push deploys the dashboard, the auth callback, the Stripe webhook, and the file upload endpoint. There is no second service to keep in sync, no shared types crossing a network boundary, no second deploy pipeline.

Astro can host route handlers and added typed server actions in version 4.15 with Zod validation built in (Astro Actions docs). It is genuinely capable for backend work. But the moment you need a long-lived process, a worker queue, or a websocket, Astro pushes you to a separate runtime, and the integrated story breaks.

Sessions, auth, and middleware

SaaS apps live on session cookies. Next.js middleware runs on every request, can read and rewrite cookies, can check auth state, and can redirect anonymous users to /login before any page renders. The pattern is documented and the community libraries (NextAuth, Supabase Auth, Clerk, Lucia) all assume this surface.

Astro added a Sessions API that stores data server-side and is available inside actions, and it integrates with auth-astro and Better Auth. The catch is in the docs: sessions are not supported in edge middleware, and they require server-side rendering to function. If any page is prerendered, session data is not available on it (Astro Sessions docs). For a SaaS that means most pages, the ones that depend on the user, cannot be prerendered. The thing that makes Astro fast on marketing pages is exactly what you cannot use on the app surface.

The React 19 ecosystem lands first

A SaaS dashboard tends to lean on TanStack Query, headless UI primitives, charts, drag-and-drop, complex forms, file pickers, rich text editors. These libraries assume a single React tree. Next.js gives you that tree natively. Astro can render React islands, and you can mount any of these libraries inside an island, but every island is its own JavaScript boundary, which complicates state sharing across the page.

Concretely: in a Next.js dashboard, a sidebar filter and a chart subscribe to the same TanStack Query cache without ceremony. In Astro, two islands cannot share a React Query client out of the box without exporting a singleton through a vanilla module and wiring each island to it.

New React features land in Next.js first

Next.js 16 includes React 19.2 features such as View Transitions, useEffectEvent, and Activity for keeping background trees mounted while hidden. The React Compiler is stable and memoizes components automatically. These are the features a busy dashboard benefits from, and they ship in Next.js the moment they stabilize because the App Router tracks the React canary.

Where Astro wins

Marketing pages and pricing

For a homepage, a pricing page, a features grid, a contact form, Astro is hard to beat. The default output is static HTML with zero JavaScript and selective hydration through Islands architecture. Production reports put Astro pages around 18 KB of JavaScript versus 180 KB for an equivalent React-heavy Next.js setup, depending on framework usage and hydration choices. For Core Web Vitals on a marketing site, that gap matters.

Documentation

Documentation is a content tree with code blocks, search, and small interactive widgets. That is the shape Astro was built for. Starlight, Astro's official docs starter, gives you search, sidebar nav, code highlighting, and i18n out of the box, and the result is a static site that loads in under a second on a 3G connection.

Content blogs

For a content blog, Astro's content collections plus the Content Layer API in Astro 5 make Markdown and MDX a first-class citizen. Server Islands let you inject personalized snippets (cart, profile picture, A/B variant) into a page that is otherwise fully static (Astro Server Islands docs). The result is a blog that ships zero JavaScript on every article and stays in green on Core Web Vitals.

What about a hybrid?

The pattern that comes up often: marketing site on Astro, app on Next.js, two separate deployments under different subdomains (www and app). It is a valid architecture and we have shipped it. The cost is real:

• Two repositories, two CI pipelines, two deploy targets, two sets of environment variables.
• Authentication state has to cross subdomains: cookie domain, CORS, OAuth redirect URLs.
• Design tokens and component primitives have to be shared, usually as a private npm package.
• Analytics, feature flags, error reporting, and observability stacks all run twice.

For a team of two, the overhead is not worth the bundle savings on marketing. For a team of fifteen with a dedicated content team and a marketing site that pulls real organic traffic, it can be. The trigger is not technical, it is org-shape.

What we use and why

For Studio's own site and every SaaS we shipped in 2026, the answer is Next.js. The reasons in order:

1. One codebase, one deploy, one runtime. Marketing pages and the authenticated app live under the same router. Adding a new dashboard route is a file in /app/dashboard. Adding a new pricing page is a file in /app/pricing. No subdomain stitching.
2. The session story is settled. Middleware runs on every request, reads the auth cookie, and redirects unauthenticated users before render. Junior developers extend it without reading framework source.
3. The React 19 features land first. View Transitions, the React Compiler, server actions, and refined caching APIs (updateTag, revalidateTag) ship in Next.js the day they stabilize.
4. The downside, bundle size on marketing pages, we mitigate with route segments that opt out of client components and with disciplined component boundaries. Our marketing routes ship under 50 KB of JavaScript without leaving Next.js.

If a client comes to us with a content-heavy site (around 100 pages of structured editorial, no authenticated app), Astro is the right answer and we will not push them to Next.js. The framework choice follows the product shape, not our preferences. For everything we would call a SaaS, the shape says Next.js. See also our take on the React Compiler in production and on Server vs Client Components for how we structure those Next.js apps day to day.

In 2026 both frameworks are mature enough that picking either is defensible. The question is which problem you are solving. SaaS means an app first, content second. That ordering makes Next.js the safer default.

Sources

• Next.js 16 release notes (Vercel)
• Astro Islands architecture
• Astro Sessions API
• Astro Actions
• Astro Server Islands
• Alex Bobes, Astro 2026 deep dive
• Aalpha, Astro vs Next.js 2026