Every kickoff reaches this question inside the first hour, and by then the client has usually been given an answer by someone with a stake in it.
We build and maintain both, so we have no house stack to sell. What we have is a short list of questions that make the choice fall out on its own. This is how we run that conversation in our web development work.
What each one is for
WordPress runs over 40 percent of the web, per W3Techs' ongoing survey. That figure matters for a practical reason: the ecosystem around it is deep and well supported. Whatever you need the site to do, something has probably already been built for it, and that something has a maintainer and documentation behind it. Ongoing maintenance stays straightforward, and the people who will edit the site after launch can usually be trained in an afternoon.
Next.js is for sites that behave like products. Custom interfaces, application logic, data that lives in your own database and gets queried in ways an off-the-shelf CMS was never designed to handle. We build Postgres-backed Next.js applications, and the line between "a site" and "software" blurs fast at that end; plenty of projects that start as a Next.js website end up in our software and SaaS practice.
Both are good tools with long track records. The failure mode is picking one for reasons that have nothing to do with the project in front of you.
The six questions
| Question | Leans WordPress | Leans Next.js |
|---|---|---|
| Who edits content, and how often? | Non-technical staff, weekly or daily | Developers, or content that rarely changes |
| What has to integrate? | Common tools with existing plugins | Custom APIs, internal systems, your own database |
| Performance targets | Good is good enough | Hard budgets on load and interaction |
| Budget | Favors proven plugins over custom code | Allows building components from scratch |
| Expected lifespan | Three to five years, then a redesign | Long-lived, growing in scope |
| Hosting and ops | Managed host, low operational burden | Node hosting, someone owns deployments |
Read down the columns. If five of six point the same direction, the decision is made and the conversation moves on to something that matters more. Mixed results mean the project genuinely sits on the boundary, and then we weigh whichever factor the client will feel every week. That is almost always the first row.
The first row is also the question that predicts regret. A marketing team that publishes twice a week and wants to rearrange a landing page on a Thursday afternoon will be miserable in a system where every change is a pull request and a deploy. WordPress hands them a page builder and a preview button, and that is worth more than any architectural argument.
The reverse holds too. If content changes twice a year and the site's value sits in a custom interactive tool, a CMS admin is overhead that nobody logs into.
There is a middle path we use often: a headless CMS behind a Next.js front end. It costs more than either pure option, so we recommend it when the editing need and the custom-interface need are both strong. Suggesting it by default would be padding the invoice.
The practical constraints
Integrations. A booking system or an email platform with a maintained WordPress plugin is a week of work. Written against a REST API in Next.js, the same integration takes longer. Flip the case around and it reverses: connecting to an internal system that no plugin covers is easier in Next.js, because you are writing the client either way and nothing is fighting you.
Performance. WordPress can be fast. Getting there takes discipline about hosting, caching, and plugin count. Next.js starts fast and stays fast with less effort, because rendering strategy is a per-route decision you make deliberately. If you have specific numbers to hit, that control is worth paying for.
Hosting and ops. Managed WordPress hosting is a solved problem at a predictable monthly price. Next.js hosting is also solved, on different platforms, but somebody has to own the deployment pipeline after handover. Ask who that person is before you pick the stack, since the honest answer sometimes decides it.
Lifespan. A site you expect to replace in three years should be cheap to build and cheap to maintain. A site you expect to keep growing for a decade justifies the up-front cost of owning your own code. Rebuilding a WordPress site is routine; rebuilding a custom application is a project.
What we run, and why it proves nothing
sciqi.com is Next.js. We picked it because the site does things a plugin does not cover, and because we wanted per-route control over rendering. Those reasons apply to us; they may not apply to you.
We also maintain WordPress sites that would be worse off rebuilt in Next.js. Their owners publish constantly, their integrations are all covered by plugins, and their maintenance bill is low precisely because we are not maintaining custom code. Moving them would cost money and buy nothing.
If a studio only ever recommends one stack, you are hearing about their hiring rather than your project. Ask which projects they have talked out of their default, and what the reasoning was.
Getting to an answer
Most projects resolve in one call. Bring the six questions, answer them honestly about who is really going to edit the site, and the stack usually picks itself before the call ends. The interesting work starts after that decision, in the content model and the interface.
Tell us what you are building and who has to run it afterwards, and we will walk the table with you. Our web development team works in both, and you can start a project once the direction is clear.