Headless CMS development separates the place where people edit content from the website, app or kiosk that presents it. Editors work in Strapi, Sanity, Contentful or a CMS shaped around their workflow, and every channel reads that content through an API. The public site can then be a fast Next.js or Astro frontend, released on its own schedule, while the content model stays stable for years.
Contents
At CodeWiz we design that model, set up the CMS, build the frontend and connect preview, webhooks, search and caching. A publish should show up on the live site quickly, drafts should stay private, and the same article should be reusable on a landing page, in a mobile app and in a newsletter without being copied into three back offices.
This service is for marketing teams whose theme fights every new layout, for companies maintaining a website and an app from two different tools, and for organisations that want structured content: products, locations, authors, FAQs and campaigns as data, ready for the next channel.
Strapi Setup for Headless CMS Development
Strapi is an open-source Node.js CMS you can run on your own server or on Strapi Cloud. The admin is familiar: content types, a media library, draft and publish, roles and an API that is generated from the model. We choose it when you want the content database and the uploads on infrastructure you control, with REST and GraphQL available to the frontend.
What a Strapi setup includes
- Content types designed around reuse: a shared SEO component, relations between authors and articles, and repeatable blocks where the page truly varies.
- Roles for authors, editors and developers, with draft and publish so a half-written page never becomes public.
- Locales when the site is multilingual, planned in the model from the start.
- Media stored locally or in object storage, with sizes that match the frontend.
- API tokens scoped to read published content, and a separate token for preview.
- Webhooks that tell the frontend to refresh a path after publish, unpublish or delete.
- A Docker or systemd deployment, backups of the database and uploads, and updates we can roll back.
Custom behaviour stays in Strapi policies, controllers and lifecycle hooks: a slug that must be unique per locale, a webhook that also notifies a search index, or a field that only certain roles can change. The Strapi docs cover the building blocks. We hand over the project with a short editor guide, environment examples and the content types committed so a new environment can be recreated.
Sanity Configuration and Structured Content
Sanity keeps content in its hosted Content Lake and keeps the editing interface, Sanity Studio, as a React application in your repository. The schema is code. That suits teams who want content models reviewed in pull requests, structured text that is hard to break, and a studio we can reshape around the way editors actually work.
How we configure Sanity
A typical article type is a few fields with validation, a slug sourced from the title, and Portable Text for the body. Portable Text stores paragraphs, headings and custom blocks as data, so the same body can render on the web and in an app:
export default {
name: 'article',
title: 'Article',
type: 'document',
fields: [
{ name: 'title', type: 'string', validation: (Rule) => Rule.required() },
{ name: 'slug', type: 'slug', options: { source: 'title' } },
{ name: 'body', type: 'array', of: [{ type: 'block' }] },
],
}- Schemas, desk structure and custom inputs live in Git, next to the frontend.
- GROQ queries request only the fields a page needs, and the Sanity CDN caches published reads.
- Drafts and published perspectives keep preview honest: editors see unpublished changes, visitors see the last release.
- Presentation mode puts the live page beside the form when visual editing is worth the extra wiring.
- Webhooks and GROQ-powered projections trigger a rebuild or an on-demand revalidation.
Sanity’s documentation is the reference for GROQ, the image pipeline and the studio. Our delivery is the schema, the studio customisation, the queries the frontend uses, and a dataset layout that separates production from staging.
Contentful Integration for Managed Content
Contentful is a fully hosted CMS. Spaces hold environments, content types, entries, assets, locales and roles. The Content Delivery API serves published content from a CDN, the Preview API serves drafts, and the Management API is how we migrate models without clicking through the UI for every change. We recommend it when many people edit, locales matter, and a managed platform is worth the subscription.
Integration work is the part that makes Contentful feel like your system. We model types and references, write migration scripts so environments stay in sync, map locales to the frontend’s language switcher, and subscribe webhooks to publish, unpublish and archive events. Preview uses the Preview API with a draft secret on the frontend. Roles follow the real organisation: an agency might edit campaign entries and be unable to change global navigation.
SaaS pricing grows with users, locales, roles and API usage. We design the model and the cache so you are paying for editors and content, with the public site reading cached API responses. Entries that are only needed at build time stay off the hot path.
Custom Headless CMS Development
A CMS built for your workflow is the right project when a product CMS would bend the process, or when the content has to live in a database you already operate. A Laravel application with a Filament admin can expose the same JSON a Strapi install would, with your orders, branches or inventory in the same system. WordPress can also sit behind a headless frontend, through the built-in REST API or WPGraphQL, when editors already know the WordPress admin and the public theme is what you want to replace.
When a custom CMS earns its cost
- Editors need screens that match an internal process: approve, translate, schedule, then push to three sites.
- Content and business data are the same records, and copying them into a separate SaaS would create two sources.
- Data-residency or contract terms require the database on your VPS, in a region you choose.
- Licence or per-seat fees would outgrow the build cost of a focused admin.
The deliverable is an admin people can be trained on in an afternoon, a versioned API, permissions, preview, and a migration from the old site. We keep the editorial UI boring and the content model explicit, so a future Next.js or Astro frontend can replace today’s site without a content migration.
Choosing a Headless CMS
The platform follows who edits, where the data may live, and how often the model will change. This is the comparison we walk through in discovery.
| Strapi | Sanity | Contentful | Custom CMS | |
|---|---|---|---|---|
| Where it runs | Your server or Strapi Cloud | Content hosted by Sanity, Studio in your repo | Fully hosted | Your server |
| Schema | Admin, exportable to code | Code, reviewed in Git | Admin plus migration scripts | Code, beside the app |
| API | REST and GraphQL | GROQ and GraphQL | REST and GraphQL | The API you design |
| Editors | Classic admin, roles, drafts | Real-time Studio, structured text | SaaS UI, locales, roles | Screens for your workflow |
| Strong fit | Open-source control, self-hosting | Models owned by developers | Many editors, managed ops | Unique flow, or data that stays in your database |
| Cost shape | Hosting and maintenance | Usage-based SaaS | Usage and seats | Build time, low licence cost |
Directus and Payload are other open-source options we look at when their admin or data model is closer to the job. The wrong choice is usually the one picked for a feature demo, before anyone listed the content types and the people who will edit them.
Frontends, Preview and Every Channel
A headless CMS still needs a frontend someone is proud to publish. For marketing and documentation sites we often use Astro: mostly static HTML, islands of interactivity where a page needs them. For products with accounts, previews and frequent updates we use Next.js, with static generation where content is stable and server rendering where it is personal. Both read the same API as a future mobile app.
What makes publishing reliable
- Preview with a draft token, so an editor opens the real page before pressing publish.
- A webhook that revalidates only the paths that changed, plus a scheduled full refresh as a safety net.
- SEO fields on every public type: title, description, canonical, social image. Sitemaps and redirects ship with the frontend.
- Search via Typesense when the CMS search box is too simple for a catalogue or a docs site.
- HTML cached at the edge. Our notes on Cloudflare configuration and on PageSpeed work are the same standards we apply here. Google’s guidance is an LCP under 2.5 seconds; a static or edge-cached page is how we get there.
- Locales mapped to real URLs and hreflang, when the CMS already stores translations.
Omnichannel is a consequence of the model. A store locator, a product sheet and a help article can feed the website, an in-store screen and a partner feed because they were modelled as data. We only promise the channels we actually wire up, and we leave the API stable so the next one is an addition.
Common Headless CMS Mistakes We Fix
- Pages modelled as a single rich-text blob. The app and the next redesign then have nothing structured to reuse. We split out the fields that are data.
- HTML pasted into the CMS. Presentation belongs in the frontend. The CMS stores headings, images, quotes and the occasional custom block.
- Preview postponed until launch week. Editors need it on day one, or they will publish to check spacing.
- A webhook nobody monitors. If revalidation fails silently, the CDN keeps yesterday’s page. We log failures and alert.
- One admin role for everyone. Authors, reviewers and developers get separate permissions, including on preview tokens.
- The whole content tree on every page. Queries ask for the fields that page renders, and list pages are paginated.
What Drives the Cost of a Headless Project
After a content audit we estimate in phases: model and CMS, frontend for the first set of templates, migration, then search, locales or extra channels. These are the factors that change the size.
- Model: number of types, relations, custom blocks and validation rules.
- Editorial UX: a default admin is smaller than custom inputs, visual editing and multi-step workflows.
- Frontend: a marketing site with a handful of templates is smaller than an app with accounts and personalised pages.
- Migration: a few dozen pages is a structured import; years of WordPress posts, media and redirects is its own phase.
- Languages and integrations: locales, site search, commerce, CRM and a second channel each add a defined piece of work.
How We Work
- Discovery: we inventory existing content, the people who edit it, the channels you publish to and the rules a draft must pass.
- Plan: we choose the CMS, draw the content model, and agree the frontend, preview and hosting approach, split into a first release and a later list.
- Build: CMS, API and frontend move together on a staging URL editors can already try.
- Test: we run a real editorial pass: create, preview, publish, unpublish, permissions, and a performance check on the key templates.
- Launch: we migrate content, keep redirects from old URLs, turn on webhooks and cache, and watch the first publishes with you.
- Support: model changes, editor questions, CMS and frontend updates, and the next channel when you are ready for it.
Why CodeWiz
- CMS and frontend in one team: content model, Next.js or Astro, hosting, cache and SEO are designed together, so publish and performance are the same project.
- A platform that fits the workflow: Strapi, Sanity, Contentful or a custom admin, chosen after the content audit.
- Open-source first: Strapi, Astro, Laravel and WordPress stay portable. A hosted CMS is recommended when its editing experience earns the fee. More about CodeWiz.
- Performance as part of the build: cached HTML, lean queries and measured Core Web Vitals, with LCP treated as a launch check.
- Fair pricing, remote by default: CodeWiz was founded in 2023 by Dragan Plavšić in Banja Luka and works with clients locally and abroad. Premium development without premium prices is how the phases are scoped.
Frequently Asked Questions
How much does headless CMS development cost?
It depends on the CMS, the number of content types, how custom the editor must be, and whether we are also building the frontend and migrating an existing site. A focused marketing site on Strapi or Sanity is a smaller project than a multilingual catalogue with preview, search and a custom workflow. After the content audit we send a written estimate split into phases.
How long does a headless build take?
A first version with a clear model and a handful of templates often reaches staging in a few weeks. Migration of a large archive, several locales or a custom admin extends that. Editors get a staging environment early, so the model can change while the rest of the templates are still being built.
Is a headless CMS better than WordPress?
WordPress remains a strong choice when editors want pages, posts and plugins in one admin. A headless CMS is the better fit when the same content must serve a site and an app, when the frontend should be a static or React application, or when the current theme has become the bottleneck. WordPress can also be the headless CMS, if the admin is what your editors want to keep.
Which CMS should we pick?
Pick Strapi for open-source self-hosting, Sanity for a schema you want in Git and highly structured text, Contentful for a managed platform with many editors and locales, and a custom CMS when the workflow or the data cannot leave your own application. We make that call in discovery, after seeing the content and the team.
Will editors find a headless CMS harder?
The admin can be simpler than a page builder, because each type shows the fields that matter and hides the layout. The new habit is preview: editors open the real page, then publish. We name fields in their language, write a short guide and sit through the first real publishing session.
Can you migrate our current site?
Yes. We map old pages and posts onto the new types, move media, generate redirects for URLs that change, and check a sample of pages with you before launch. Content that is only layout, not data, gets a deliberate decision: migrate it, or rebuild that section as structured fields.
Ready to Separate Content from the Website?
Tell us what you publish, who edits it and which channels have to stay in sync. We will recommend a CMS, a content model and a first release. Contact CodeWiz to start, or see our headless CMS development service.