Headless & Next.js development
Headless, but only when it earns its keep
Headless splits a website in two: a content back end your team keeps using, and a Next.js front end that renders it. Done for the right reasons it is the fastest thing we build. Done for the wrong ones it doubles the number of systems you own and turns a typo fix into a deployment.
- Front end
- Next.js App Router, React
- Content back end
- WordPress, Sanity or Payload
- Rendering
- Static + incremental
- Starting at
- $2,700
The problem
Most headless rebuilds solve the wrong problem
A site is slow, someone says the word headless, and six months later there are two codebases, a deploy pipeline, a preview environment that half works, and a page that still takes three seconds because the images were never the issue.
Decoupling answers real constraints: several front ends sharing one content source, a content model too large for a theme to express, rendering that has to happen at the edge, or a product application and a marketing site that should share components. It is not an answer to a bloated plugin list, and it is a poor answer to “the site feels dated”.
When the case is genuinely there
- The same content has to feed a website, an application and a partner feed
- Traffic is global and time to first byte from one origin is the bottleneck
- Your product is a React application and the marketing site is a separate, inconsistent world
- Editors need to publish into a structure far richer than pages and posts
- A launch, a sale or a press hit has taken the site down before
- You already employ front-end engineers and have no appetite for PHP templates
For reference
Which stack we would actually recommend
We build in all of these, so the recommendation costs us nothing either way. This is the conversation we have on the first call, written down.
| Your situation | What we would build | Why |
|---|---|---|
| A marketing site your team edits daily | Custom WordPress, no page builder | One system, one login, no deploy step for a typo. Editors get instant preview and the performance ceiling is higher than people assume. |
| Marketing site plus a React product | Next.js front end, headless CMS behind it | Components, design tokens and auth are shared instead of diverging, and the marketing pages stop being a codebase nobody owns. |
| A large structured catalogue — courses, listings, documents | Next.js with a headless CMS modelled to the content | Here the content model is the product. Expressing it in pages and custom fields works until it does not, and that wall is expensive to hit late. |
| Existing WordPress, good content, bad front end | WordPress kept as the back end, Next.js in front | Your editors keep the admin they know and the project is scoped to the layer that is actually broken. |
| A store with real inventory and fulfilment | Shopify, and headless Shopify only if the storefront demands it | Headless commerce gives up a large amount of built-in storefront behaviour. Rebuilding checkout edge cases is rarely the best use of the budget. |
| One brochure site, five pages, small budget | Neither — a custom WordPress build or a single static site | Headless adds a second system to host, monitor and update. At this size that cost buys you nothing. |
What is included
What a headless build actually contains
The Next.js application
- App Router with server components by default and client components only where interaction requires them
- A typed data layer — the CMS schema generates the types the pages consume
- Route-level loading and error boundaries, so a slow or failed fetch never blanks the page
- Image handling through next/image with correct sizes and priority hints
- A revalidation strategy written down per route, not guessed per deploy
The content back end
- WordPress with a REST or GraphQL layer, or a dedicated headless CMS where the model justifies it
- A content model designed around what editors publish, not around templates
- Draft preview that renders in the real front end rather than an approximation
- Roles and permissions that match who actually publishes
- Media handling and transforms configured once, at the source
Caching and revalidation
- Tag-based revalidation wired to CMS webhooks, so a publish invalidates only what changed
- An explicit cache policy per route — static, revalidated or dynamic — with the reason recorded
- Stale-while-revalidate behaviour, so an editor never waits on a build
- A full-rebuild path that still works on the day webhooks fail
- Cache behaviour verified against real response headers, not assumed from the docs
Rendering and performance
- A performance budget enforced in CI, held to the same target as our own site: Lighthouse ≥ 95
- Server-rendered HTML for everything that matters to search and AI crawlers
- Font loading, script loading and third-party tags audited before launch
- Bundle analysis with a documented ceiling per route
- Core Web Vitals re-measured on field data after launch, not only in the lab
Deployment and environments
- A Git repository you own, with a preview deployment on every pull request
- Separate production, staging and preview environments with their own content sources
- Environment variables and secrets documented, in accounts held in your name
- A rollback that is one action, and that has been tested
- Uptime and error monitoring configured before launch rather than after the first outage
Handover
- An architecture document describing both halves and how they talk
- A runbook for the three things most likely to go wrong, with the fix for each
- Editor training recorded against your real content
- A written statement of what we would change next, and why we did not do it now
- No proprietary layer — another team can take the repository and continue
The engineering detail
The parts that decide whether headless hurts
Headless projects rarely fail at the design stage. They fail at caching, at preview, and at the moment an editor asks why their change is not live.
Rendering: choose a strategy per route, in writing
Next.js lets a route be statically generated, incrementally revalidated, or rendered per request. Mixing them is correct; mixing them by accident is how a page nobody expected becomes dynamic and the response time triples.
- Static for anything that changes on a publish rather than on a request
- Incremental revalidation for lists and archives that change often
- Per-request rendering only where the output genuinely depends on the visitor
- Record the choice beside the route, so the next developer does not have to infer it
Revalidation: the webhook is the whole contract
An editor publishes, the CMS fires a webhook, the front end invalidates the tags that content touched. If that chain breaks, the site is silently stale and looks completely fine — which is the worst failure mode available.
- Tag content so one publish invalidates the page, its listings and nothing else
- Log every webhook received, and alert when none arrive for longer than expected
- Keep a manual revalidation route behind authentication for the day it breaks
- Never rely on a nightly full rebuild as the primary mechanism
Preview: editors will not adopt what they cannot see
A draft has to render in the real front end, with the real components, at a URL an editor can send to a colleague. Anything less and your team starts publishing to production to check layout.
- Draft mode behind a signed preview token, not a guessable public URL
- Preview rendered by the same components as production
- A visible indicator that the page being viewed is a draft
- Preview tested with the people who will actually use it, before launch
Two systems means two sets of updates
You now own a CMS and a JavaScript application. Both have security updates and breaking major versions, and the front-end framework moves considerably faster than the back end does. That is the recurring cost of this architecture and the line most proposals leave out.
- Dependency updates on a schedule, applied to a preview deployment first
- A pinned, documented runtime and framework version per environment
- A named owner for the deployment platform account and its billing
- Budget for a framework major upgrade roughly once a year
Crawlers read the HTML you actually send
Server components help here, but a route can still ship an empty shell with the content arriving on the client. Classic search engines will usually wait for it; several AI crawlers do not render JavaScript at all.
- Check the raw HTML response, not the rendered DOM in the inspector
- Keep critical copy out of client-only components
- Emit structured data server-side so it exists in the first response
- Verify that platform bot protection is not returning a 403 to crawlers you want
WordPress can stay — it is often the right back end
Going headless does not require abandoning WordPress. Keeping it as the content layer preserves the admin your editors know, the plugins that genuinely earn their place and the editorial workflow, while the front end becomes a Next.js application.
- REST or GraphQL, chosen on what the front end actually queries
- Custom fields exposed deliberately, field by field, rather than wholesale
- Editors keep their existing login and their existing workflow
- The rebuild is scoped to the front end, which roughly halves the risk
Our process
How we decide, then how we build
The first phase can end with us recommending that you do not do this. It is far cheaper for everyone at week one than at week twelve.
Understand needs
Find the actual constraint
What is limiting you: time to first byte, the content model, the number of front ends, or your team’s ability to ship? Each one points at a different architecture, and only some of them point at headless.
You getA written constraint analysis and a stack recommendation
Strategize
Model the content and the cache together
How content changes determines how it can be cached, so these are one decision rather than two. Route by route, we agree what is static, what revalidates and what genuinely has to be dynamic.
You getContent model, route map and caching plan
Create & build
Back end first, then the front end
The CMS, the schema and working preview land before the pages, so design is built against real content rather than placeholder text. Every pull request deploys a preview URL you can open.
You getPreview deployments per branch, reviewed route by route
Optimize & grow
Launch, then watch the headers
Cache hit rates, revalidation behaviour, field vitals and error rates through the first weeks. Headless failures are usually caching failures, and they show up in the data before anyone reports them.
You getPost-launch performance and caching review
Honest scoping
When headless is right — and when it is a tax
Worth it if
- You have, or will pay for, developers who can maintain a JavaScript application
- Content has to serve more than one front end
- Your content model is genuinely complex and a theme is fighting you
- Traffic is spiky or global and caching at the edge is a real requirement
- A React product already exists and the marketing site should share its components
Not worth it if
- Your team edits daily and wants changes live in seconds without a deployment
- The site is slow because of plugins and cheap hosting — that is a far cheaper fix with the same result
- You have no in-house engineering and no plan to retain any
- The site is small and will stay small; you would host two systems to serve five pages
- The reason is that headless sounds modern. It is an architecture, not a positioning
One more thing. Plenty of the people who ask us for a headless build are better served by a custom WordPress theme and better hosting. We would rather say that on the first call than three months in.
Questions
Before you ask us
The things people ask about Headless & Next.js Development before they get in touch. If yours is not here, ask directly — you will get a straight answer rather than a brochure.
Ask a questionIs a headless site faster than WordPress?
Usually, but less dramatically than the pitch suggests, and never automatically. A custom WordPress theme on good hosting with a sane plugin list is fast — both stacks meet the 1.4s average LCP we hold our own work to. Headless wins where edge caching and per-route rendering control genuinely matter. It loses whenever the real problem was unoptimised images, a page builder or the hosting, because changing architecture fixes none of those.
Can my team still edit the site?
Yes, and this is the part to pin down before committing. Content stays in a CMS with a normal editing interface, draft preview renders in the real front end, and publishing triggers revalidation rather than a manual deploy. What changes is that layout is code: a request to move a section becomes a developer task rather than a drag.
Do we have to move off WordPress?
No. WordPress as a headless back end is one of the most common versions of this build and often the best one — your editors keep the admin they know and the project replaces only the front end. We would move you to a dedicated headless CMS when the content model is the actual reason for the project.
What does a headless build cost to run?
Builds start at $2,700, and the running cost is what people underestimate: you are hosting a CMS and a front-end application, and maintaining two dependency trees. Expect a framework upgrade to need real attention roughly once a year. We put the running cost in the proposal rather than leaving it to be discovered in month four.
Will this hurt my SEO?
Not if it is server-rendered, which is how we build it. The risks are specific and avoidable: content that only appears after client-side JavaScript, URLs that change without redirects, and metadata generated on the client. Each is a decision rather than an inevitability. If you are moving an existing site, the URL inventory and redirect work from our migration service applies here too.
Could we start on WordPress and go headless later?
Often the sensible path. If the content model is sound and the admin is clean, adding a Next.js front end later is a front-end project rather than a rebuild. What makes the later move expensive is building the WordPress site badly now — so the decision that matters today is the content model, not the renderer.
Tell us the constraint, not the architecture
Describe what is actually limiting the site — speed, the content model, the number of front ends, your team. We will tell you whether headless is the answer, and we will say so when it is not.