WordPress or Next.js: how I decide what a business site is built on

Every project starts as the same question wearing different clothes: what should this be built on? It is usually asked as a technology question — WordPress or something modern, a page builder or a framework, the thing the last agency used or the thing the next one is selling. It is almost never answered well as a technology question, because the technology is the least important part of the answer.

The live builds on this site make the pattern visible. Two schools, a clinic, a solar installer, a construction firm, a fencing association and a study-notes library all run WordPress. An astrology tool for a specific audience is Next.js. None of that is accidental, and none of it came from preference. Each choice fell out of three questions, asked in order.

Question one: who edits the site next month?

This is the deciding question in most projects, and it is the one agencies skip because the answer is inconvenient for whatever they prefer to build. A website is not finished at launch — it is handed over. The real question is who it is handed over to.

A school publishes notices, fee structures, book lists, circulars and galleries all year, and the office has to do it without a developer on the phone. That is a content operation, and WordPress is a content operation’s tool: the admin is familiar, the user roles exist, drafts and revisions work the way an office expects, and the person doing the publishing has probably used it before at another job.

The senior secondary school build on this site carries its statutory Mandatory Disclosure section, per-session fee structures, online e-registration and photo galleries — all maintained by the school, none of it waiting on me. The preschool runs its own admissions announcements the same way. That independence is what the platform choice bought, and no framework however elegant buys it for a non-technical office.

Question two: is it a site, or is it a tool?

Some projects look like websites but are actually applications. The astrology product on this site validates number sequences against a fixed grid with instant feedback, in Hindi, installable to a phone home screen. There is no editor, no posts, no pages in any meaningful sense — there is logic and an interface to it.

Building that in WordPress means fighting the platform: bending a content system into an application shape, carrying a database and an admin that nothing uses, and paying WordPress’s maintenance overhead for none of its benefits. Building it in Next.js means writing the tool and nothing else. The site arrives as static HTML, there is no admin to secure, and nothing needs updating on a schedule.

The same logic ran the other way for the clinic. It needed a treatment catalogue — fourteen procedures, each with its own page — and a store selling products through the same install. That is content plus commerce, the exact centre of what WordPress and WooCommerce are for.

Question three: what does maintenance actually look like?

WordPress sites carry a standing maintenance duty: core updates, plugin updates, PHP version bumps on the host’s side, backups that must actually restore. None of it is hard, but all of it is real, and a site that nobody maintains degrades towards the day it breaks. If a business has nobody to do this — no agency, no retainer, no in-house habit — that cost belongs in the decision.

A static Next.js build inverts the profile. There is nothing to patch on a schedule and no admin login to attack, but every content change is a developer task. For a site whose words change twice a year, that trade is excellent. For a site that publishes weekly, it is a tax on every single update.

• Choose WordPress when the site lives on published content, a non-technical person runs it day to day, or commerce needs to sit beside services in one install.
• Choose Next.js when the thing is really an application — logic, interactivity, an interface to a system — and the content rarely changes without a developer involved anyway.
• Either can be fast, and either can be slow. Speed is a build-quality question, not a platform one.
• Distrust anyone whose answer is the same for every client. The platform should fall out of the questions, not precede them.

The honest overlap

Plenty of projects sit in the overlap where either answer works, and pretending otherwise is salesmanship. A marketing site could be either, and I have shipped that call in both directions — the deciding factor each time was the team running the site afterwards, not the framework. The same React brief that suits a marketing team comfortable with a developer workflow would be the wrong call for a school entirely — not because React cannot render a school website, but because the school could not run it afterwards.

One more honest note: the choice is less permanent than it feels, but migration is never free. Content moves between platforms; design and integrations get rebuilt. Choosing well the first time is cheaper than choosing fashionably and migrating later.

The stack is a consequence of who runs the site — not a badge.