Did Your Project Really Need Next.js?

A pattern is emerging in the JavaScript ecosystem. Teams are migrating off Next.js - not in frustration, but in recognition that they chose the wrong tool for the job. Inngest cut local development time by 83% after switching to TanStack Start. OpenPanel and Documenso have told similar stories. Each case is worth reading, and each one raises the same underlying question: was Next.js ever the right fit?

What Next.js is actually built for

Next.js is an opinionated framework with server-side rendering at its core. It was built to pre-render content, serve HTML immediately, optimise for SEO, and deliver fast initial page loads. The ideal use cases are clear: blogs, news sites, marketing pages, public product catalogues, SEO-driven e-commerce. Applications where the content can be pre-rendered, and where search engine visibility directly affects the business.

For those projects, it remains an excellent choice. The App Router, React Server Components, and incremental static regeneration are genuinely powerful tools when applied to the right problem.

When the mismatch shows up

The trouble starts when teams apply Next.js to applications that are nothing like those use cases. Highly interactive internal tools. SaaS dashboards with complex state and frequent data updates. Applications where almost every page is gated behind authentication and SEO is irrelevant. In these cases, pre-rendering provides no benefit, and the framework's SSR-first architecture introduces friction at every turn.

Inngest's engineers described fighting the framework rather than shipping features - spending time navigating use client and use server boundaries, layered cache APIs, and the mental overhead of distinguishing between server and client components. Local page loads reached 10 to 12 seconds. That is not a performance problem unique to Next.js; it is what happens when an SSR-first framework is used to build what is essentially a client-side application.

Where TanStack Start fits in

TanStack Start takes the opposite approach. It is client-first by default, with SSR available as an explicit opt-in rather than the architectural starting point. The mental model is simpler for teams building interactive, data-heavy applications: route, query, mutation, invalidation. There is no constant decision about whether a component belongs on the server or the client, because the answer is almost always the client.

For teams whose applications were never genuinely SSR-first, moving to TanStack Start removes a layer of complexity they were never benefiting from.

Framework should follow architecture

None of this means Next.js was a mistake as a technology - only that it was, in many cases, the wrong tool for the problem at hand. The migrations happening now are largely corrections, not condemnations.

For our own work - public-facing websites, API-backed frontends, content sites where SEO matters - Next.js continues to be the right call, and we have written about why we prefer React and Next.js in more detail. The framework should follow the architecture, not drive it. If your project is genuinely SSR-first, Next.js is hard to beat. If it was never meant to be, the migration stories above are worth a read before your next greenfield decision.