The Next.js Exodus: When Your Meta-Framework Becomes the Bottleneck

Every few years, the web development world coalesces around a dominant framework. For the past three years, Next.js has been that framework — the default starting point for React projects, the safe choice on every shortlist. But something has shifted in 2026. Railway migrated its entire production frontend off Next.js and cut build times from ten minutes to under two. Northflank publicly announced they were ditching it and never looking back. Dozens of smaller teams are quietly making the same move.

This is not a pile-on. Next.js remains a capable framework with genuine strengths. But the growing exodus reveals something important about how frameworks evolve, and when the tool that launched your project becomes the thing holding it back.

TL;DR

• A growing number of companies — including Railway and Northflank — are migrating production frontends away from Next.js in 2026, citing build performance, complexity creep, and vendor coupling.
• The App Router migration introduced significant cognitive overhead without proportional benefit for client-heavy applications.
• Vite + TanStack Router has emerged as the leading migration target for teams whose applications are primarily client-rendered.
• Framework migration is a legitimate engineering decision, not a trend to follow blindly — evaluate based on your actual pain points.
• A two-phase migration strategy (decouple dependencies first, swap the framework second) dramatically reduces risk and downtime.

What Is Actually Driving the Migration?

The reasons teams cite for leaving Next.js cluster around three themes: performance friction, complexity without proportional value, and concerns about platform coupling.

Build Performance Has Become a Bottleneck

Railway’s case is instructive. Their frontend serves millions of users across more than 200 routes. Build times had crept past ten minutes, with six of those minutes consumed by Next.js alone — half of it stuck on what the framework calls “finalising page optimisation.” For a team shipping multiple times per day, that is not an inconvenience. It is a drag on velocity that compounds with every deploy.

This is not unique to Railway. As Next.js projects grow, build times tend to scale non-linearly. The framework’s bundling, code-splitting, and optimisation passes — designed to produce optimal production output — become increasingly expensive. For teams practising continuous deployment, every minute in the build pipeline is a minute of delayed feedback.

The App Router Complexity Tax

Next.js 13 introduced the App Router, a fundamental architectural shift from the Pages Router that had served the framework well for years. The App Router brought React Server Components, nested layouts, parallel routes, and a new mental model for data fetching. For greenfield projects with heavy server-rendering requirements, these are genuine advances.

But for the substantial number of Next.js applications that are primarily client-side — single-page applications with authentication, dashboards, admin panels — the App Router introduced cognitive overhead without proportional benefit. Teams found themselves wrestling with “use client” directives, debugging hydration mismatches, and navigating an increasingly complex caching system that was difficult to reason about.

The result? Many teams were using a server-first framework to build client-first applications. The architectural mismatch created friction at every level: slower builds, harder debugging, more complex deployment, and a steeper learning curve for new developers joining the team.

Vercel Coupling Concerns

Next.js is open source, but its most powerful features — edge middleware, incremental static regeneration, image optimisation — work best (and sometimes only) on Vercel’s platform. As teams grow, the gap between “Next.js on Vercel” and “Next.js anywhere else” becomes harder to ignore.

Self-hosting Next.js is possible but requires navigating a maze of configuration that the framework’s documentation treats as a secondary concern. For teams that need multi-cloud strategies, on-premise deployment, or simply want to avoid vendor lock-in, this coupling is a strategic risk, not just a technical inconvenience.

Where Are Teams Going?

The migration targets vary depending on the application’s actual needs, but a clear pattern has emerged.

Vite + TanStack Router

This combination has become the default destination for teams with client-heavy applications. Vite’s build performance is dramatically faster — Railway’s builds dropped from over ten minutes to under two. TanStack Router provides type-safe routing with a file-based convention that feels familiar to Next.js developers, but without the server-rendering overhead.

The appeal is simplicity. Vite does one thing exceptionally well: bundling. TanStack Router does one thing exceptionally well: routing. There is no framework magic, no implicit server behaviour, no caching layer to debug. What you write is what runs.

Astro for Content-Heavy Sites

Teams whose Next.js applications are primarily content sites — blogs, marketing pages, documentation — are finding Astro’s island architecture a better fit. Astro ships zero JavaScript by default and hydrates only the interactive components that need it. For content-first sites, this produces dramatically better performance with far less complexity.

SvelteKit for Full-Stack Simplicity

Teams that genuinely need server-side rendering but want a simpler developer experience are exploring SvelteKit. Svelte’s compile-time approach eliminates the runtime overhead of React’s virtual DOM, and SvelteKit’s conventions are deliberately minimal compared to Next.js’s growing feature surface.

When Migration Actually Makes Sense

Framework migration is expensive. Even Railway’s well-executed migration — completed in just two pull requests — required deep knowledge of both the source and target frameworks, careful routing of traffic, and thorough testing across 200+ routes. For most teams, migration should be a last resort, not a response to Hacker News discourse.

Migration makes sense when:

• Build times are measurably impacting your deployment cadence. If you are deploying less frequently because builds take too long, that is a concrete cost you can quantify.
• Your application’s architecture does not match the framework’s assumptions. If you are building a client-heavy SPA on a server-first framework, you are paying complexity tax for features you do not use.
• Vendor coupling is creating strategic risk. If your deployment options are constrained by framework-platform dependencies, that limits your negotiating position and disaster recovery options.
• Developer experience is suffering. If onboarding new developers takes weeks because the framework’s mental model is too complex for your use case, that is a real cost.

Migration does not make sense when:

• Your application genuinely benefits from server-side rendering and Next.js’s features align with your needs.
• Your team is productive and build times are acceptable.
• You are on Vercel and happy with the platform — the tight integration is a feature, not a bug, when it works for you.
• You are chasing a trend rather than solving a measurable problem.

How to Execute Without Burning the Team

Railway’s two-PR approach is worth studying. Rather than attempting a big-bang rewrite, they broke the migration into two discrete phases:

1. Phase one: decouple. Remove Next.js-specific dependencies, abstractions, and patterns. Replace next/image with standard <img> tags or a framework-agnostic image component. Replace next/link with standard anchor tags. Extract data-fetching logic from getServerSideProps or server components into plain functions. The goal is to make your application framework-agnostic before changing the framework.
2. Phase two: swap. With dependencies decoupled, the actual framework swap becomes mechanical. Replace the routing layer, update the build configuration, and verify everything works. This phase should be boring — if it is exciting, phase one was not thorough enough.

This approach has a crucial advantage: phase one is entirely reversible. If the migration stalls or priorities change, you still have a working Next.js application. You have simply made it cleaner and less coupled — which is valuable regardless of whether the migration completes.

The Broader Lesson

The Next.js exodus is not really about Next.js. It is about the lifecycle of framework adoption. Every framework starts as a simplification — a way to avoid the complexity of what came before. Over time, successful frameworks accumulate features, conventions, and opinions. Eventually, for some subset of users, the framework’s complexity exceeds the complexity it was designed to eliminate.

This is not a failure. It is an inevitability. The question is not whether your framework will eventually become a bottleneck, but whether your team has the awareness to recognise when it has, and the discipline to migrate methodically rather than reactively.

At REPTILEHAUS, we help teams navigate exactly these decisions — evaluating whether a framework migration is worth the investment, planning the execution to minimise risk, and building on the architecture that actually fits the application. If your frontend stack is creating more friction than it solves, get in touch. We have been through this before.

📷 Photo by Ilya Pavlov on Unsplash