Headless CMS
- Structured, typed content
- Roles, workflow, localisation
- Visual preview for editors
Headless CMS architecture, built around how you publish.
Content modelling and CMS implementation on Sanity, Contentful, and friends, designed around your editorial workflow instead of the platform's defaults.
Why headless
Why decouple content from the site?
Headless isn't automatically better. It's better when content needs to outlive the page it was written for.
Content outlives templates
Content is modelled as structured data, so a redesign doesn't mean re-entering everything.
Reuse across pages and channels
The same content can serve a landing page, an email, an app, and a partner feed.
Real editorial workflow
Roles, drafts, review stages, scheduling, and audit trails, rather than one shared edit surface.
Localisation done properly
Multi-locale content with translation workflow built into the model, not bolted on later.
Front end is free to change
The site can be rebuilt or replatformed without touching the content layer.
Governance at scale
Multi-brand and multi-region publishing with permissions that reflect your org chart.
What's included
What a CMS engagement covers.
- Content audit and inventory
- Editor experience design
- Draft, review, and scheduling
- Migration from the current CMS
- API design for other consumers
- Ongoing model evolution
- Content modelling workshops
- Visual editing and live preview
- Localisation and translation workflow
- Front-end integration
- Editor training and documentation
- Schema design and validation
- Roles and permissions
- Asset and DAM strategy
- Webhooks and build triggers
- Governance and naming conventions
Architecture
How it fits together.
If the website will always be the only consumer and the team is small, we'll often recommend a simpler visual CMS instead.
Astro or Next.js
- Content pulled at build or request
- Component-based front end
- Webhook-triggered rebuilds
Site, app, channels
- Website is one consumer
- Apps and partners use the same API
- One source of truth
What we implement.
Sanity · Contentful · Astro Content Layer · Storyblok · Payload · WordPress (headless) · Vercel · Cloudflare
Tools: Sanity, Contentful, Astro, Vercel
Honest assessment
When headless is overkill.
Headless adds a layer. That layer earns its keep in some organisations and quietly taxes others.
Go headless when
- Content feeds more than one surface
- You need real roles and approval workflow
- Multi-brand or multi-region publishing
- Localisation is a genuine requirement
- Content volume is substantial
- The front end will change over time
Skip headless when
- The website is the only consumer
- The team is two people and one workflow
- Page count is small and stable
- Nobody will maintain the content model
- A visual CMS would genuinely be enough
FAQs
Headless CMS questions.
Sanity or Contentful?
Sanity when the content model needs flexibility and the team is comfortable with a more developer-shaped tool. Contentful when enterprise workflow, permissions, and predictability matter more.
Do editors lose visual editing?
No, if it's set up properly. Both platforms support live preview, and we add visual page composition on top so editors aren't editing abstract fields.
Can we migrate our existing content?
Yes. Content migration is scripted and reconciled page by page, the same approach we use for platform migrations.
Who owns the content model afterwards?
You do, and we document it. Models drift when nobody owns them, so we agree naming conventions and a change process during the build.
Can we keep WordPress as the back end?
Yes, running WordPress headless is a legitimate middle path when editorial teams are deeply invested in the admin experience.