Headless WordPress — WordPress as an API, with a separate front end in something like Next.js — is either exactly right or an expensive detour, and the deciding factors are unglamorous. This is the version of the decision we’d give you on a call.
What you actually gain
The real wins are narrower than the pitch, but where they apply they’re decisive.
- Front-end freedom. App-grade interactions, state, and routing without fighting the theme layer.
- One content source, several front ends. A website, a mobile app, and a partner portal reading the same content is genuinely hard the classic way and natural headless.
- Independent front-end deploys. Your interface can ship on its own cadence and its own infrastructure.
- A smaller public surface. The admin can live somewhere the public never reaches.
What you give up — and this is the part that gets skipped
Every convenience WordPress gives you for free is convenience you now rebuild. Honestly accounted for, that list is long:
- Preview. “See how this looks before publishing” is no longer free. It’s a feature you build.
- Most of the plugin ecosystem. Anything that renders on the front end — forms, SEO output, page builders, consent banners — stops applying. You reimplement what you need.
- The editing experience. Editors lose the direct connection between what they edit and what they see, unless you invest in restoring it.
- One system to run. Two codebases, two deploy pipelines, two sets of environment variables, two places a problem can be.
None of these is a reason not to go headless. They’re the price, and the projects that go badly are the ones that didn’t know they were paying it.
The four questions that decide it
1. Is the front end an app, or a site?
Accounts, dashboards, multi-step flows, real-time state — that’s an app, and headless earns its keep. Pages of content with a contact form is a site; classic WordPress will serve it faster and cheaper.
2. Does more than one client need this content?
Two or more genuine consumers of the same content is the single strongest argument for headless. One consumer rarely justifies it on its own.
3. Who edits, and how often?
Editors publishing daily and expecting to see their work in context need preview and predictable layouts — budget for rebuilding those. A quarterly content change makes the trade-off much easier.
4. Who maintains it after launch?
Headless assumes ongoing front-end engineering capacity. If nobody owns the front end in twelve months, that is the real risk — not the architecture.
The in-between option people forget
You don’t have to go all-in. A conventional WordPress site with one or two genuinely app-like sections built against the same API gets most of the benefit at a fraction of the cost and complexity. Marketing pages stay editable and previewable; the booking flow or the member dashboard gets the front end it needs. For mid-market teams this is very often the right answer, and it’s rarely the one being proposed.
Our own bias, stated plainly: we build both, so we don’t need this decision to go a particular way. If a classic build does the job, that’s a cheaper project and we’ll say so.
