Sound familiar?
- The same content is copied into your website, app and partner portals by hand
- Your site is slow because the CMS renders every page on every request
- Developers want a modern front end but editors want to keep the CMS they know
- You publish to several brands or regions from one team
- Your Shopify theme cannot deliver the content-rich experience you want
Key facts
- Headless separates content management from the front end; content is delivered as JSON through REST or GraphQL APIs
- We use WordPress (REST API or WPGraphQL), Strapi, Payload, Sanity or Contentful depending on the project
- Front ends are usually Next.js with static generation and on-demand revalidation
- One content source can feed a website, mobile app, kiosk or in-store screen
- Shopify headless builds use the Storefront API, with Hydrogen as one option
- Live preview and publish webhooks are set up so editors see changes before they go live
- Fixed-price quote after a free chat
What headless means, in plain terms
In a traditional CMS such as standard WordPress, the system that stores content also builds the web pages. In a headless set-up those jobs are split. The CMS stores and manages content and exposes it through an API. A separate front end, usually built with React and Next.js, fetches that content and turns it into pages.
That split brings real benefits: faster pages served from a CDN, a front end built with modern tools, and one content source that can feed a website, an app and other channels at once. It also brings costs: two systems to host and maintain, and features that a traditional CMS gives you for free, such as previews, menus and forms, have to be built deliberately. Headless is the right answer for some projects, not all.
When headless makes sense
| Headless is a good fit when | Traditional is usually better when |
|---|---|
| Content feeds a website, app and other channels | Content only goes to one website |
| Speed and Core Web Vitals are commercially critical | A well-built traditional site is fast enough |
| You have, or will have, developers maintaining the front end | Editors want to change layouts without a developer |
| You need a rich storefront on top of Shopify or another commerce engine | The standard theme does the job |
| Several brands or regions share one content team | One brand, one site, a small team |
If you are on the right-hand side, a well-built WordPress site is likely to serve you better for less. We will say so.
Choosing a CMS
- WordPress as a headless CMS keeps the editor your team knows, exposing content through the built-in REST API or WPGraphQL. Good for migrating an existing WordPress site to a faster front end.
- Strapi is an open source, self-hosted Node.js headless CMS with a flexible content-type builder and REST and GraphQL APIs.
- Payload is an open source TypeScript CMS that can run inside a Next.js application, so content and front end deploy together.
- Sanity and Contentful are hosted content platforms with strong editing tools and global APIs, paid by usage tier.
- Directus sits on top of an existing SQL database, which suits projects where the data already lives somewhere.
We choose based on who edits, how content is structured, hosting preferences, budget for subscriptions and whether data must stay on your own servers.
Front ends that are fast and still editable
We usually build the front end in Next.js. Pages are generated ahead of time and served from a CDN, then regenerated on demand when content changes: the CMS sends a webhook on publish, and the affected pages are revalidated within seconds. Visitors get static-site speed, editors see their changes go live quickly.
The parts that often get forgotten are the parts editors care about most, so we build them in from the start:
- Live preview of draft content in the real site design.
- Flexible page sections modelled in the CMS, so editors can build landing pages from approved components.
- Menus, redirects and SEO fields managed in the CMS, not hard-coded.
- Image handling with automatic resizing and modern formats.
- Forms that post to your CRM or email platform.
Headless commerce
The same approach works for ecommerce. Shopify's Storefront API lets a custom front end handle browsing and baskets while Shopify still runs checkout, payments and orders. Shopify's own Hydrogen framework is one way to build this; Next.js with the Storefront API is another. Magento's GraphQL API supports the same pattern. Content from a headless CMS can be blended with product data, which suits brands whose stores are as much about storytelling as catalogue. See Shopify development.
Headless commerce adds cost and complexity compared with a standard theme, so we recommend it only when the standard theme is clearly holding the business back.
Starting a headless project
We start with a free chat about your content, channels, editors and plans. From there we model the content, recommend a CMS and front-end approach, and give you a fixed-price quote. If you are moving from an existing CMS, we migrate content and keep URLs or redirect them so search rankings are protected. Get in touch.
What we deliver
- Content modelling: types, fields and relationships designed around your content
- CMS set-up and configuration, self-hosted or SaaS
- A Next.js or React front end with static generation and revalidation
- Editor previews, publishing workflows and roles
- APIs feeding mobile apps, partner sites and other channels
- Migration of content from an existing CMS with URLs preserved
How it works and what it costs
Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.
Free chat
Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.
Scoping
We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.
Fixed-price quote
You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.
Build and test
We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.
Hand over and look after
You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.
Frequently asked questions
What is a headless CMS?
A headless CMS stores and manages content but does not build the web pages. It delivers content through an API to a separate front end, such as a Next.js website or a mobile app. dijitul uses this approach when content must feed several channels or speed is critical.
Can we keep WordPress and go headless?
Yes. WordPress can act as a headless CMS through its REST API or WPGraphQL, so editors keep the interface they know while dijitul builds a faster Next.js front end. Some WordPress plugins that output front-end features need replacing, which we assess during scoping.
Is headless better for SEO?
It can help through faster pages, but only if the front end is server-rendered or statically generated, with proper metadata, sitemaps and redirects. dijitul builds headless sites with Next.js to cover those basics, and keeps SEO fields editable in the CMS.
Which headless CMS do you recommend?
It depends on your editors, hosting and budget. dijitul often uses WordPress for teams that know it, Strapi or Payload when content should be self-hosted and open source, and Sanity or Contentful when a hosted platform with strong editing tools suits better.
Can editors preview content before publishing?
Yes. dijitul sets up draft previews so editors see unpublished changes in the real site design before going live, along with publish webhooks that refresh the affected pages within seconds of publishing.
How is a headless CMS project priced?
We do not publish prices. After a free chat dijitul scopes the content model, CMS, front end and integrations, then gives a fixed-price quote. Larger builds are phased, each with its own fixed price.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.