A headless build for sites where the content is the business

What this actually solves

The organisations that need this share a shape. They publish a lot, they publish continuously, and their content has structure that a page-based system flattens. A recruitment firm with job listings that have employers, cities, salary bands and closing dates. A magazine with articles, authors, sections and series. A manufacturer with several hundred products that share specifications. In each case the content is not a set of pages — it is a set of things with properties, and it is presented in many places.

Two failures usually bring them here. The first is performance at scale: a traditional CMS assembling every page from a database on every request, plus the accumulated plugin weight of several years, gets slow in exactly the way that costs money when most visitors arrive from search on a phone. The second is structural. The content was modelled as pages, so a piece of information that logically belongs to a product now lives in five different pages of formatted text, and any change means finding all five. Nobody can produce a listing of every job in a given country because the country was never a field.

Going headless separates the two concerns. Content lives in its own system as structured data with relationships between records. The site is a separate application that reads that data and renders it — most pages built ahead of time and served as static files, which is why they are fast. The same content can then feed anything else you build without being duplicated. The price of this is that it is a real engineering project with a real architecture decision at the front, and getting that decision wrong is expensive in a way that only becomes visible about a year later.

What we do, and in what order

1. Model the content on paper, before touching any software. What types of thing exist in your business, what fields each carries, what genuinely belongs to it versus what merely appears near it, and how they reference each other. We work through the awkward cases deliberately: what happens to a job listing when it closes, what a product with no image should do, whether a category is a field or its own document. This session is the highest-leverage part of the whole engagement. Two to four days.
2. Implement the schema and set up the editing environment. The model built in the CMS with field descriptions written for the people who will use them, sensible validation, and the studio arranged so an editor sees their own work in a comprehensible order rather than an undifferentiated list of documents. Three to five days.
3. Build the front end. Next.js, with the rendering strategy chosen per route rather than globally — pages that change rarely built ahead of time, pages that must be current rendered per request, and the reasoning recorded so whoever maintains it later understands why. Then listing pages, filters, search and pagination, which is where most of the real complexity in a content site actually lives. Two to four weeks.
4. Wire up preview and the publishing workflow. Draft content rendered in the real design at a private URL, so editors are not typing into a form and hoping. Publication triggers a rebuild of the affected pages, which is verified by publishing something and watching it appear. Three to five days.
5. Migrate the existing content. Scripted rather than manual once past a few dozen items — mapping old fields to new, converting formatting, moving images and rewriting their links, preserving dates and authorship. Then the URL map: every old address redirected to its new one, checked by crawling the old site's URLs against the new site rather than spot-checking a handful. One to two weeks, depending on volume and how consistent the old content is.
6. Launch, then train the editors. The full pre-launch checklist, redirects verified, sitemap generated, analytics confirmed receiving data. Then a session with the people who will use the system daily, recorded, covering their actual document types. Three to four days.

What moves the price

The range is $2,500–$12,000 over 4–8 weeks, and three factors account for most of the spread.

How much old content has to come across. This is the largest single variable. Four hundred posts from an aging installation, with inconsistent formatting and images scattered across several locations, is a substantial project in its own right and is quoted separately from the build.

Whether the site is multilingual. Adding languages is not a translation task bolted on at the end — it changes the document model, the routing, the editorial workflow and the fallback behaviour when a translation does not yet exist. It has to be a decision at the start and it materially changes the number.

How much the editors need from their environment. A standard editing interface is included. Custom preview panes, bespoke input components, approval workflows and role-based permissions are each real engineering, and they are worth buying when a large team publishes daily and worth skipping when two people publish weekly.

What usually goes wrong

The content model is built to match the current design. A field ends up named for the box it appears in on today's homepage. The design changes within the year, that box no longer exists, and the field survives as something nobody can interpret. The model should describe things that exist in your business — a job listing, an employer, a city — not the page where they happen to be displayed this quarter. This is the single most expensive mistake available in this project, and it does not become visible for about eighteen months.

Migration is treated as an afterthought. The build is scoped and quoted, and the several hundred existing articles are assumed to be a weekend job. They are not. Worse, the URL mapping gets skipped, the old addresses return errors, and search traffic that took years to earn disappears in the first month after launch — an outcome that is very hard to explain and harder to reverse. Migration and redirects are planned as their own phase with their own time.

Editors are handed a system with no preview. They are asked to fill in fields and trust the result, which is a reasonable thing to refuse. What follows is predictable: publishing slows down, people start pasting formatted text from a word processor to feel in control, the content becomes inconsistent, and eventually somebody proposes going back to the old system. Preview is not a nicety on a headless build; it is what makes the whole arrangement acceptable to the people who have to live in it.