Headless CMS in practice: what we have learned shipping Sanity projects
Headless CMS has been a buzzword for years now, but the gap between the pitch and the reality is still wider than most agencies admit. We have shipped multiple Sanity-powered sites and learned some things the hard way.
The pitch is real but incomplete
The core promise of headless is sound. Decouple your content from your presentation layer and you get freedom: freedom to redesign without a content migration, freedom to serve the same content across web, mobile, and print, freedom to use the best front-end tools without being constrained by your CMS.
What the pitch leaves out is that freedom has a cost. Someone has to build the presentation layer from scratch. Someone has to wire up preview, build the image pipeline, handle redirects, set up on-demand revalidation, and create an editing experience that non technical content editors can actually use without calling a developer.
What we have learned
Schema design matters more than you think
The schema is the contract between your content team and your front-end. Get it wrong and every page build involves a translation step. Get it right and the content flows naturally into components without ceremony. We spend more time on schema design than on any other phase of a Sanity project.
Editors need guardrails, not freedom
A blank portable text field is not a good editing experience. We use field-level validation, custom input components, and opinionated schemas to make it hard for editors to produce content that breaks the front end. The goal is that anything they can save will render beautifully.
Preview is non negotiable
If your editor cannot see what their changes look like before publishing, you have built half a CMS. We set up draft mode and live preview on every Sanity project. The extra day of engineering pays for itself in the first week of content entry.
The CDN layer needs thought
Headless sites are fast by default, but caching strategy still matters. We use incremental static regeneration with webhook driven cache purging when an editor publishes a change, only the affected pages rebuild. The rest of the site serves from the edge instantly.
Is headless right for you?
If your content team is small, your site has fewer than fifty pages, and your design needs are straightforward probably not. A well configured WordPress install will serve you better at a fraction of the cost.
But if you have complex content relationships, multiple output channels, or a front end that needs to evolve independently of your content model, headless is worth the investment. Just make sure whoever builds it has shipped one before. Contact us to discuss your Sanity project.