Skip to content

Headless CMS

Headless CMS and editor tooling

We set up headless CMS (Sanity, Contentful, Payload, Storyblok) so marketing and content people can publish themselves — without compromising performance or your design system.

3D illustration of two transparent glass blocks connected by a glowing orange data thread — a layered content block on the left, a lit screen block on the right, on a dark navy grid surface.

CMS as a tool, not an obstacle

What we design in from the start

Modelled to your real content
Schema
Draft mode on real pages
Preview
Workflow and publish approval
Roles
Localisation that doesn't melt down
i18n

How we think about CMS

A tool — not an obstacle.

A CMS isn't a piece of software — it's the environment your content team spends half their working day in. A bad CMS doesn't just cost you developer time; it costs you campaigns that never ship, translations that never get done, and marketing folks who learn to work around the system instead of with it. We set up headless CMS so it feels like a tool, not an obstacle.

We work with Sanity, Payload, Contentful and Storyblok — all four are good platforms in different contexts. Sanity often wins when you have complex schemas and developers close to the content; Payload when you want the CMS close to your own Postgres stack; Contentful when the org is large and governance weighs heavily; Storyblok when marketing needs to assemble pages visually. We pick with you based on where you stand — not based on what we have in stock.

What we build isn't just a configuration. It's schemas that mirror your content the way it actually lives (not the way a developer thinks it should look), preview modes that show changes on real pages before publish, localisation that doesn't melt down at language 4, roles and workflows so review and publish follow your governance, and a developer experience where frontend folks can build new components without waiting on CMS permissions.

What we deliver

Schemas, preview, localisation and workflow.

Sanity, Payload, Contentful or Storyblok — set up so marketing can publish without a developer.

  • Schemas designed for your content

    We model your content types together with you. Page-builder blocks for marketing, structured entities (products, cases, people) for permanent content, and fields validated so you don't discover errors after publish.

  • Live preview and draft mode

    Editors see changes on the real pages — not in some abstract preview. With draft mode, multiple people can work on a page in parallel and publish together when it's ready.

  • Localisation without the pain

    A field can be per-locale or shared. Translators get a workflow with only the fields that need translation. Hreflang is set correctly on the frontend so Google understands the language relationships.

  • Roles, workflow and publish approval

    Content can require sign-off from an editor before going live. Per content type, per language, or per environment. Audit log on who changed what — important when you're multiple brands or multiple markets.

  • Asset management and image pipeline

    Images uploaded once, cropped on demand in the frontend via on-demand transforms (Sanity, Cloudinary or Vercel Image). Proper alt text enforced as part of the workflow, not as an afterthought.

  • APIs for frontend, mobile and partners

    Content is accessed via GraphQL or REST. Cache and revalidate strategy designed in so Next.js, native apps and partner integrations all read from the same source without hammering the CMS.

Before you pick a platform

What you should consider first.

  • Sanity, Payload, Contentful or Storyblok?

    Depends on your size, content complexity and how comfortable your team is with code. We give an honest recommendation in discovery — typically Sanity for most technically heavy sites, Payload when you want the CMS in your own database, Contentful for large orgs with strict roles, Storyblok when visual page building matters most.

  • Schemas are hard to change later

    A page builder with 50 blocks isn't necessarily better than one with 10 thoughtful blocks. We spend time designing the schema with your editors in discovery — that's the investment that pays back the most. Migration of existing content is usually part of scope.

  • Localisation: per field or per document?

    Per-field localisation is flexible but gives you complex schemas and editor experience. Per-document is simpler but requires discipline when parts of the content are shared. We choose based on how much of your content actually needs translation — and it's rarely all of it.

  • Hosting, backup and data ownership

    Sanity and Contentful are SaaS — you pay for them to run infrastructure for you, but you own the content and can export it. Payload and Strapi run on your own infrastructure (we typically host on AWS or Vercel) — full control, but also full operations responsibility. We design the migration path both ways from start so you're not locked in.

FAQ

What people usually ask.

  • Can you migrate from our current CMS?

    Yes. We've migrated content from WordPress, Drupal, Umbraco, Sitecore, Episerver and quite a few custom CMSes. Migration is typically a combination of a script that pulls existing content into the new schema, and editor work to clean up things that can't be mapped mechanically. We plan it in the discovery phase so you know what's coming.

  • Can marketing build new pages themselves after launch?

    Yes — that's one of the most important design requirements. We set up a page builder with blocks for hero sections, feature grids, quotes, FAQ, image strips, CTAs and whatever your marketing typically needs. For specially designed campaigns, we build a new block in 1–3 days. Marketing should never have to wait on a deploy to ship a landing page.

  • How is preview of changes handled before publish?

    We set up Next.js Draft Mode so editors can see their changes on real pages on a secure preview domain. When they're happy, they hit publish — the cache for affected pages is cleared, and production sees the new version within seconds via on-demand revalidation.

  • Can we have multiple languages without it becoming chaos?

    Yes. We design the localisation strategy from the start — typically per-field for pages and per-document for blogs/cases. Translators get a workflow with only the fields that need translation, and you can see an overview per language of how far you are. We also support English as master with other languages as derivatives if that fits your org.

  • Should we pick a SaaS CMS or self-host?

    Both work — it's a question of where you want to spend your time. SaaS (Sanity, Contentful, Storyblok) is fastest to launch and requires no operations work from you; in exchange your content lives on a third-party platform. Self-hosted (Payload, Strapi) gives full control and the content in your own Postgres, but you (or we) need to handle updates, backups and monitoring. We walk through the choice with you in discovery based on your team, your compliance requirements and where you want to spend attention.

Ready to get started?

Let's have a no-pressure conversation.

We'll get back within one business day with concrete input — not a stock proposal.