When we still reach for Next.js — and when we do not

We just rebuilt our own site, maram.ch, on Astro after years on Next.js. That move generated a polite question from a few founders: should we be moving off Next.js too?

Almost certainly not. Here is the honest decision tree we use when we pick a front-end framework for a new product. It does not start with “what is fashionable in 2026”; it starts with “what does your product actually do”.

What we still reach for Next.js for

Next.js is excellent for products that have authenticated user sessions, server-rendered state, frequent updates, and a need for runtime API routes alongside the UI. Concretely:

• Authenticated dashboards. When the page content depends on a session token, you want server-side rendering so the initial paint is correct and SEO-irrelevant pages stay fast.
• Products with a real backend in the same repo. Next.js API routes (or Server Actions in App Router) keep the frontend and the “BFF” — backend for frontend — in one mental model. For small teams that compresses cognitive load.
• E-commerce and marketplaces. Incremental Static Regeneration (ISR) was built for this — pages cache at the edge, get revalidated on a schedule or on demand. Few alternatives match it.
• Apps that need ISR + auth + API routes together. Next.js ships these as one box. Replacing it with Astro + a separate backend + a separate cache layer is more work than the migration usually saves.

When a partner brings us one of those shapes, we still reach for Next.js. Whatchlive, the product we engineer with Donkeylab, is a Next.js application — and will stay one.

What we no longer use Next.js for

The shape Next.js is not a good fit for is the shape our own site has:

• Marketing pages with no auth and no per-user content. Every visitor sees identical HTML; we have no use for SSR, ISR, or API routes.
• Content that changes once a week, not once a minute. Build-time generation is cheaper than runtime regeneration.
• Pages that should fit in <100 KB total. Next.js ships a React runtime, a router, hydration code, and chunked bundles. For a 5-page marketing site, that is overhead we cannot justify.
• Sites operated by engineers, not editors. Without a CMS in the picture, the runtime CMS-client code in Next.js is dead weight.

For that shape, Astro is correct. Static HTML for the visitor, zero JavaScript shipped by default, view-transitions for inter-page polish, and the same component model when we need interactivity (Islands).

The decision tree, in plain language

When a new product engagement arrives, we ask these in order:

1. Does the product have user accounts? If yes — you almost certainly want SSR for the authenticated pages. That is Next.js (or Remix, or SvelteKit — pick the React/Vue/Svelte ergonomics your team is fastest in). Astro is the wrong tool.

2. Does the page content depend on per-user or per-request state? If yes — you need server rendering at request time. Same answer: Next.js / Remix / SvelteKit. Static-site generators (Astro, 11ty, Hugo) cannot serve dynamic state without a runtime layer, and adding one defeats the purpose.

3. Does the content change more often than once per build can capture? If yes (e.g., live dashboards, real-time inventory, anything that updates by the minute) — you need SSR or a streaming/edge runtime. Static is wrong.

If your answer to all three is “no” — you have a marketing site, a documentation site, a portfolio, a blog. Static is correct. Astro is correct. The build will be faster, the page weight will be lower, the hosting will be cheaper, and your visitors will get a more responsive experience.

What the migration actually cost

To be specific about the move we did — for our own site, the Astro rewrite shipped in about a week of evening work. The new build produces a 48 KB home page, the container is 21 MB content (down from a Next.js standalone build), and the dependency count went from 33 to 7.

But — and this is the part most “X vs Y framework” posts skip — the migration was justified by the product shape, not by the framework’s intrinsic merits. We did not migrate because Next.js is bad. We migrated because the constraints had shifted: we no longer needed a CMS at runtime, we no longer needed a Resend-backed contact form, we no longer wanted heavy hero animations. With those constraints gone, the right tool changed.

If our site grew an authenticated portal tomorrow, we would migrate back. The framework follows the product, not the other way around.

What we tell partners specifically

When a partner asks “should we move off Next.js?”, the honest answer is usually one of:

• “No.” You have a real product with auth and state. Next.js is the right tool for that. Migrating is a six-month distraction from shipping features.
• “Maybe — for parts of it.” Your marketing site is a Next.js app because the product is. Splitting the marketing into a separate Astro deployment can pay back in build time and page weight without touching the product itself.
• “Yes, soon.” This applies to the rare case where the product genuinely is content-only and the team accidentally built it on a SPA framework. We have seen this twice; both times the move paid for itself in three months.

The question is always shape-first, framework-second.

The lesson

Frameworks are tools matched to product shapes. Next.js is the right tool for products with sessions, server state, and dynamic content. Astro is the right tool for content sites with no per-request state. Both are excellent at their job. Neither is universally correct.

The honest exercise is to write down what your product actually needs — auth, state, content cadence, page weight target — and pick from there. Most of the framework debates we read online skip this step and argue about the tools in the abstract. The tools are not in the abstract; they live in your specific product.

If you would like help running that exercise for your own product, we are an email away.