WordPress or Next.js: choosing without overpaying
3 min readNext.jsReactWordPress
Next.js is fashionable, WordPress is boring, and that is exactly why the choice often goes wrong. An honest look at when React is genuinely needed and when it only adds cost.
The question “what should we build the site on” is usually framed wrongly. The right version is: who will change the content and how often, and is there any logic here beyond showing pages.
When WordPress is the right answer
If it is a company site, a services site, a clinic, a shop - anything where content is changed by people without a developer and pages mostly present information. WordPress wins here not because it is “simpler” but because the admin and the editing are already written and proven across thousands of sites.
The main mistake on this path is believing WordPress means slow. It does not. It means slow when a builder and thirty plugins have been dropped onto it. A custom theme with ACF hits the same speed numbers as a React site, with editing that is incomparably simpler.
When Next.js is genuinely needed
- There is a user account area, roles, data behind a login - an application rather than a site.
- The interface is complex and lives in state: filters, step-by-step flows, calculators, live updates.
- There are external APIs and business logic that will have to be written either way.
- The site is large and content has to be served from the edge under load.
What these have in common is that the complexity is already in the problem. React does not add it; it gives you a way to manage it. Where that complexity is absent, React adds only development cost and a dependency on a developer for every text change.
What has changed in Next recently
The App Router and server components shifted the balance: most of a page can now render on the server and arrive as finished HTML, with only the JavaScript that interactivity genuinely needs going to the browser. In practice that means lighter pages without giving up React where it is wanted.
The second substantial thing is incremental regeneration. A page is served as static but refreshed in the background on a schedule. For content sections that gives static speed without rebuilding the site by hand.
The third option people forget
Headless: WordPress stays as the admin where the client edits content, and the front end is built in Next. You get familiar editing and a modern front end. The price is two systems instead of one - more code, and more places for something to break.
It is justified when an editorial team is large and works daily while the interface demands more than a theme comfortably gives. For a ten-page site it is overkill.
A technology is never right in itself. It is either suited to the problem or more expensive than the problem.
How to decide in five minutes
Ask yourself: will somebody edit this site without me every week? If yes, you need a proper admin, and that argues for WordPress. Is there logic, state and data behind a login? If yes, that argues for Next. If both answers are yes, you are looking at headless and should be ready to pay for two systems.