Next.js or WordPress: how to decide without a developer’s opinion

1. The question behind the question

When you ask a developer this question, you will usually get an answer shaped by what they are good at. That is not dishonesty; it is how expertise works. A WordPress specialist has solved a hundred problems in WordPress and will reach for it. We build in Next.js, and you should read everything below with that in mind.

So it helps to reframe. The technology is not really the decision. The decision is: who edits this site, how often, how custom does it need to be, and what does it have to connect to? Answer those four honestly and the technology usually picks itself.

This article is written so you can reach that answer without needing to trust either of us.

2. What you are choosing between

WordPress is a content management system

It arrives as a finished application: a login screen, an editor, a media library, and a theme that decides how pages look. You install it, and most of a website already exists. Functionality is extended with plugins — pre-built packages that add a booking form, a store, a gallery. More websites run on it than on anything else, which means a large pool of people who can work on yours.

The trade-off is that you are assembling a site from parts other people designed. When your requirement matches an available part, that is enormously efficient. When it does not, you spend the project persuading a component to be something it was not built to be.

Next.js is a framework you build in

Nothing exists until it is written. There is no editor, no theme, no plugin directory — those are things the build includes deliberately or not at all. In exchange you control precisely what the browser receives, which is why pages can be pre-built and served as finished files rather than assembled on every visit.

One is a house you furnish. The other is a plot you build on. Neither is the better purchase in the abstract.

3. When WordPress is right

We do not build WordPress sites, and we will still tell you to use one when the following describes you. Getting this wrong is expensive in a direction that is hard to reverse.

• Someone non-technical needs to publish new pages every week, and nobody wants to involve a developer to do it.
• The site is mostly articles, events or notices, and the design can sit comfortably inside a theme.
• You need a specific piece of functionality that already exists as a mature plugin, and building it fresh would cost more than it is worth.
• The budget genuinely cannot stretch past a template, and a working site this month beats a better site next quarter.
• Your team already knows WordPress, and that knowledge is worth more than any technical gain from switching.

The first point carries the most weight. If publishing is frequent and must not involve a developer, WordPress solves that on day one, and every alternative has to earn its way past it.

4. When Next.js is right

The case for building rather than assembling is strongest when your requirements stop matching what themes and plugins already do:

• Speed is commercially load-bearing — a store, a booking flow, anything where a slow page costs you the enquiry.
• The site has to talk to something else: an inventory system, a CRM, a payment gateway, a hospital or property database.
• The interface is genuinely custom, and you would spend the project fighting a theme into a shape it resists.
• You expect to grow past a few hundred pages, or to add a second language, a second brand or an app later.
• You want the codebase itself as a deliverable — readable, typed, and handed over as an asset you own outright.

5. The costs in neither quote

Both quotes will show you a build price. Neither reliably shows you the cost of owning the thing, and that is where the two platforms diverge most sharply:

• Plugin licencesThe serious plugins are annual subscriptions. Four or five of them is a recurring line item nobody mentions during the quote, and it does not stop.
• Update labourWordPress core, the theme and every plugin update on their own schedules, and updates occasionally conflict. Someone has to apply them and check nothing broke.
• Security responseA public, widely-used platform with third-party plugins is a larger target. Budget for monitoring and for the day something needs patching quickly.
• Developer availabilityOn the Next.js side, the pool of developers is smaller and costs more per hour than the WordPress pool. That is a real trade-off, not a footnote.
• Editing workflowA custom-built site needs its content tool built or connected deliberately. If that is skipped, every text change becomes a developer ticket — the most common regret we hear.

The shape is consistent: WordPress front-loads less cost and carries more of it forward; a custom build does the reverse. Compare the two over three years, not at signature.

6. Deciding in ten minutes

Take the four questions from the first section and answer them out loud. In our experience the decision falls out of the answers without much argument.

Who edits the site, and how often? Weekly, by a non-technical person, with no developer available — that points hard at WordPress unless something else overrules it. Rarely, or by someone comfortable with a proper tool, and the question stops mattering.

How custom is the interface? If a theme gets you most of the way, take the theme. If you are already listing exceptions, the theme will cost you more than it saves.

What does it connect to? Nothing, or one payment gateway — either platform is fine. A live inventory, a CRM, a property feed, a hospital system — that is a build.

What is it in three years? Roughly the same site with more posts — WordPress ages well at that. Ten times the pages, a second language, an app sharing the same data — plan for that now, because retrofitting it is the expensive path.

7. Questions to ask

Put these to whoever is quoting you, on either side. You are not testing their technical knowledge — you are testing whether they have thought about your second year:

• Who on my team will change page text, and what exactly do they click to do it?
• What is the total recurring cost in year two — hosting, licences, updates, monitoring — not just the build price?
• If I stop working with you, who can pick this up, and what do they receive?
• Which parts of this are custom-built, and which are a plugin or theme doing the work?
• What happens when I want a page layout the current design does not have?

Specific answers mean someone has planned the work. Reassurance without detail — “don’t worry, it’s all handled” — is itself the answer.

There is no wrong platform here, only a mismatch between what a site has to do and what it was built on. Almost every rebuild we are asked about traces back to that mismatch being made quickly, by someone who only ever used one of the two.