When Not to Use Next.js

We build in one framework and take no work outside it. That makes this the page on this site you should read most sceptically, and also the one most worth having: a firm that cannot name where its tool is wrong is describing a product, not an opinion.

Five cases. In all of them we would tell you so rather than take the project.

1. A content site with no application in it

A brochure site, a documentation set, a marketing site with a blog. If nothing on it is interactive beyond a contact form and a nav menu, Next.js is a large amount of machinery for HTML.

Astro, Eleventy or Hugo will produce the same output with a fraction of the JavaScript and a build you can explain to anyone. The React component model starts paying for itself when there is state to manage and shared behaviour to reuse. Below that line it is overhead you maintain forever.

There is a number behind this rather than a feeling. A Next.js route ships the React and App Router runtime whether or not the page uses any of it - on this site, which ships no client code of its own on any route, that floor is about 186KB gzipped. An equivalent Astro page ships nothing until you ask for something. If the page has no interactivity to justify the runtime, you are paying that on every first visit for a component model you are not using.

The honest counter-argument: if the site is one part of a product that already uses React, one framework across both is worth something. That is an organisational reason, not a technical one, and it is still a real reason. The full comparison turns on one question - what proportion of your page has to do something after it loads.

2. The team does not write React

This is the one people are least comfortable saying out loud.

A framework you are fluent in beats a better framework you are learning, for any project with a deadline. A team that ships Laravel or Rails or Django confidently will produce a better application in those than a competent Next.js application built while reading the docs - and will maintain it for years afterward without a specialist.

Choosing Next.js also means choosing its rate of change. The App Router, Server Components and the caching model have all moved substantially in three years, and 16 moved middleware, Turbopack and image defaults again. That pace is manageable with someone who follows it and expensive without.

The question to ask is not whether your team can learn it. It is who reads the release notes in eighteen months, after the person who was enthusiastic about it has moved on. If the answer is nobody, the framework will drift out of support inside your own codebase while still being actively maintained outside it, which is the worst of both.

3. The interesting work is all backend

A payments engine, a data pipeline, a scheduling system, an API with a dozen consumers. Next.js has route handlers and Server Actions, and they are good at what they are for - serving a front end. They are not a substitute for an application server.

If the system's complexity lives in queues, workers, long-running jobs, transactions across services or anything that has to survive a deployment mid-flight, you want a backend framework and a real job runner. Next.js can then be the front end that talks to it, which is a perfectly good arrangement and a very different project from "we built it in Next.js".

The specific gap is worth naming, because it is the thing teams discover late. There is no supervised worker in the framework. Nothing owns a job that fails at 3am, retries it with a backoff, and is still holding it when the deploy finishes. You can assemble that around Next.js with a queue service and a separate process, and at that point you have a backend - so the honest version of the decision is whether you want to choose one deliberately or arrive at one accidentally. Against Laravel and against Express are the same argument from two directions.

4. You need the edge and cannot have Node

Next.js has moved toward Node for request-time work. In 16 the proxy convention that replaces middleware runs on Node and the runtime is not configurable.

If your architecture depends on running logic in a hundred edge locations - geo-routing at scale, auth checks that must not touch an origin, request shaping for a global audience - that is worth checking against the framework's current direction rather than assuming. A dedicated edge platform may fit the requirement better than a framework that is de-emphasising it.

This is the least stable entry on the list, and we would rather say that than let it read as permanent. It describes where the framework is heading right now. If edge execution is central to your architecture, verify it against the version you are about to adopt rather than against this page.

5. A single interactive widget on someone else's site

A pricing calculator dropped into a WordPress page. A booking form embedded in a CMS you do not control. Next.js is a framework for owning a whole site; if you own one <div>, ship a small bundle - plain JavaScript, Preact, a web component - and skip the routing, the rendering model and the deployment target entirely.

How to tell which case you are in

Three questions, in this order. They are ordered because the first one disqualifies more projects than the other two together.

1. What proportion of the page is still doing something after it loads? Nearly none of it, and the answer is a static site generator, not a React framework.
2. Where does the project's difficulty actually live? If it lives in jobs, transactions and integrations rather than in the render path, choose the backend framework first and treat the front end as a second decision.
3. Who owns this in eighteen months? Not who builds it. Who upgrades it.

The second question is the one teams answer too quickly, because an integration looks like a fetch call until it is built. Where the pieces of one actually run is worth reading before deciding that the front end can hold all of it.

If you are choosing between two specific things rather than asking the general question, the comparison is usually more useful than this page: against Astro if the question is how much JavaScript a content site should ship, against Remix if you have already decided on a React framework, against Laravel if the application has a real back office behind it, and against Express if what you are actually building is an API.

Where it is genuinely the right answer

For completeness, because the list above is not an argument against the framework:

• An application with a public, indexable surface and an authenticated one. Rendering both well from one codebase is the thing Next.js does that alternatives mostly do not.
• Commerce, where the catalogue must be static and fast and the cart must not be.
• Anything where Core Web Vitals are a commercial number rather than a scorecard, and where you need control of the render path to move them.

If you are not sure which side of that line you are on, that is a question with a cheap answer: a fixed-scope audit that says what the stack is costing you, including the possibility that the answer is "nothing, it is fine".

One of those cases deserves its own page, because it is the most common of all: a site that is already on WordPress and working. That comparison is here, and it spends most of its length arguing against the move.