When Not to Use Next.js
We only build in one framework, which makes this the page you should be most suspicious of and the one worth reading. Five cases where Next.js is the wrong answer.
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.
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.
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.
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".
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.
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.
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".