When Next.js Is the Wrong Choice: The Limits Honest Advisors Name

Next.js is an excellent choice — and for a whole class of projects it's still the wrong one. Anyone who won't say that out loud is selling a framework as a religion. And decision-makers who have already lived through a migration can smell the gap between promise and reality from across the room.

We build Next.js applications, run them self-hosted, and pitch them at decision-maker level. That's exactly why this article exists: a technology whose limits you can't name is one you haven't understood. The honest answer to the question of when Next.js is the wrong choice is what makes the recommendation in every other case credible. There are three constellations where I advise against it — and one case where I contradict myself. For the larger picture this decision belongs in, see our overview of front-end architecture for mid-sized companies.

The most common bad decision isn't the most expensive, but it is the most visible: Next.js for a pure marketing website. A dozen pages, a bit of editorial content, a contact form, no logged-in area, no server-side business logic. For something like that, Next.js brings framework weight the user pays for in the browser.

The technical core: Next.js is a React framework. Even a largely static page carries router and hydration code with it. Comparison blogs put a Next.js marketing site at roughly 80–150 KB of JavaScript depending on setup, while Astro ships 0 KB by default and only loads JavaScript where a component is genuinely interactive. Those KB figures are rules of thumb, not primary benchmark data — but the order of magnitude holds. Astro produces static HTML, has no hydration obligation, and is conceptually leaner for content-heavy pages. For a site that stays predictably small, that's the more honest choice.

Here I have to qualify, or I'll be unfair. Next.js itself offers an SPA and static mode, and Server Components cut the JavaScript sent to the browser substantially — only components marked with 'use client', together with their import graph, reach the client bundle at all. Used with discipline, Next.js gets far closer to Astro than the raw numbers suggest. The point is not that Next.js is slow. The point is that for a task Astro solves with fewer moving parts, you learn, operate and maintain a larger framework across its versions. Complexity is a cost line even when it carries no licence fee.

For editorially driven sites there's a third path developers like to overlook: a classic or headless CMS where non-developers maintain content without a deploy pipeline. Whether you're building a platform or a publication decides more than any framework benchmark. Draw the line cleanly between a content system and an experience platform and the architecture almost picks itself — something we've written about at more length, including the difference between a CMS and a DXP.

The second reason to advise against it appears nowhere in the sales brochure: Next.js has an active development cycle with genuine breaking changes. That's not an accusation — a framework that moves stays relevant. But movement costs, and those costs land in your maintenance budget, not in marketing.

Concretely: version 15 made cookies, headers, params and searchParams asynchronous, made React 19 mandatory, and stopped caching fetch by default. With version 16, synchronous access to those request APIs was removed entirely, Node.js 20.9+ became mandatory, and Turbopack became the default — a build with its own webpack configuration simply fails without the --webpack flag. Add changed next/image defaults and further adjustments. No single release is dramatic, but it adds up: run a Next.js application across three or four years and you take on regular upgrade maintenance that a static Astro build or a hosted CMS just doesn't have.

One widespread misconception deserves correcting here, because it poisons the discussion so often: Next.js 16 does not abolish middleware. It's renamed to proxy and deprecated, then runs on the Node.js runtime. If you need the Edge runtime, the docs say you can still use middleware. Anyone telling you middleware has "gone away" hasn't read the changelog. Precision on details like this is the difference between a risk assessment and pub talk.

The most underestimated item is the App Router migration. Many teams started in 2023 and 2024 expecting the move off the Pages Router to be a configuration matter. It isn't.

Next.js itself recommends an incremental, page-by-page migration and, in its own migration docs, speaks openly of new concepts, mental models and behavioural changes to be learned. That's vendor language for: this is work. Forced changes include getServerSideProps and getStaticProps to async Server Components, getStaticPaths to generateStaticParams, _app and _document to app/layout.js, next/head to the Metadata API, pages/api to Route Handlers, and next/router to next/navigation. Each of those lines gets explained in passing — in a grown codebase, each one is refactoring with a testing burden attached.

Real-world reports confirm it. One engineering team described running Pages and App Router in parallel as drawn-out, had to switch error handling entirely to Error Boundaries, and could no longer use the runtime config they'd relied on before. The mental model of RSC caching — when something is static, dynamic or revalidated — is the actual learning curve, not the syntax. In a much-watched GitHub discussion, a clear majority of more than 2,000 participants voted for the Pages Router. That poll is self-selecting, opinionated and partly overtaken by newer versions — as proof of a majority it doesn't hold. As a signal that the switch created friction, it's worth taking seriously.

For you as a decision-maker that means: if a service provider quotes a Next.js migration without a separate line for the router switch, check the numbers. A clean first implementation of a self-hosted Next.js stack runs us a one-off 5,000 to 20,000 euros; a migration with substantial Pages Router legacy can exceed that, because it's refactoring rather than a new build. Anyone who wants to go from pitch to go-live in 90 days plans such conversions in rather than discovering them mid-project — we've described what that looks like in our account of the path from pitch to go-live.

The third case is a hiring question, not a tech question. Next.js is React. If your team lives in a different stack — Vue, classic server-side rendering, a Java world — you pay the learning curve twice: once in the build, once permanently in operations.

The market does favour React. In the Stack Overflow Developer Survey 2025, somewhere between a third and nearly half of respondents used React, well ahead of Angular, and among professional developers React leads more clearly still. Developer availability is therefore strategically on React's side. But the market average doesn't help your specific team if it can't write React today. Introducing a framework whose mental model — Server vs. Client Components, caching behaviour, hydration — nobody internally carries creates a vendor lock-in at the service-provider level that rarely gets priced in. You're then buying not just code, but the necessity of keeping that provider.

And there's the budget boundary. Self-hosting on Hetzner is GDPR-compliant in Germany from roughly 20 to 50 euros a month, with operations costing two to five hours monthly for updates, monitoring and backups. That's cheap — but it's operational responsibility. For a tiny project on a tight budget that's exactly the bad trade: the saved platform costs get eaten by operating time, and the genuinely hard part of self-hosted Next.js — ISR caching across multiple instances with a custom cacheHandler — is rarely needed in small setups, yet still has to be understood the moment you scale. We've laid out the whole platform-versus-self-hosting trade-off in our comparison Next.js on Hetzner instead of Vercel.

Now I'll contradict myself, deliberately. In several of the cases where Next.js looks wrong by these criteria, I'd still choose it.

Take the "simple" marketing website. It grows surprisingly often. Five pages become a customer portal, the contact form becomes a login, the publication becomes a platform. Pick the Astro or website-builder path early and you repay that bet later with a migration — and a migration after three years of growth costs more than the initial overengineering ever would. The bet on the React and Next.js ecosystem can be right for precisely the project that looks too small for it today.

Then there's hiring and continuity. For React you find developers, libraries, patterns and answers. That's a real value that outweighs a momentary learning curve. When I choose between the theoretically better-fitting niche tool and the framework I can still staff in two years, the ecosystem often wins — even against my own overengineering critique. Performance is rarely the counter-argument here: with Server Components and ISR, a cleanly built Next.js delivers good Core Web Vitals that ultimately feed through to conversion and revenue.

The boundary is therefore not a formula. It's a weighing of time horizon and team. A throwaway project with fixed scope and a Vue team: not Next.js. A platform with unclear growth, a React-leaning team and a horizon measured in years: almost always Next.js, even if it starts small today.

Ask two questions before you order Next.js or reject it. First: is this going to grow? If the answer is an honest no — a campaign microsite, a brochure, a project with an end date — take Astro, Vite or a CMS and spare yourself the framework and the migration risk. Second: who carries this? If nobody in-house can write React and nobody is meant to learn it, you're buying a vendor lock-in with Next.js that costs more than any licence.

If everyone involved says yes to both — it's growing, and we can or want to carry React — then Next.js is almost always right, and the breaking changes and the migration become a priced-in maintenance line, not a deal-breaker. Distrust any provider who sells you Next.js for everything, and equally any who damns it wholesale. The right answer has a date, a team and a time horizon. Whoever names the limits has understood what they're recommending — and that's exactly who I'd believe.