Building a Headless CMS-Backed Marketing Site That Content Teams Love
Our first headless CMS marketing site, built on Contentful with a Next.js frontend, was technically clean — fast, well-typed content models, good preview support. The client's content team hated using it. Every page required assembling content across four or five separate content types with no visual sense of how the final page would look until it was published, and the marketing team ended up routing every change through us because they couldn't confidently self-serve.
For the next build, we switched to Sanity specifically for its Presentation tool, which gives content editors a live visual preview alongside the editing form, updating as they type rather than requiring a separate deploy or preview URL. That single change did more for adoption than any of the technical architecture decisions — the content team could see what they were building in real time, the same way they could in WordPress, without giving up the structured content model a headless CMS provides.
We also rethought content modeling around how marketers actually think about pages rather than how a database schema wants to be normalized. Instead of forcing every page into rigid, separately-managed content types, we built a flexible page builder with a defined set of reusable content blocks — hero, testimonial grid, feature comparison, CTA banner — that a content editor can add, reorder, and configure without engineering involvement, while still keeping the underlying data structured enough for the frontend to render predictably.
Preview links for stakeholder review were a requirement we underestimated on the first project. Marketing needed to share a working preview of an unpublished page with a client stakeholder for approval before it went live, and building that properly meant securing preview mode behind a signed, expiring token rather than an open preview URL, since some of this content included pricing changes not yet public.
The measurable outcome on the second project: content team tickets requesting engineering help with page changes dropped from several a week to roughly one a month, almost entirely for genuinely new page templates rather than routine content updates. The lesson wasn't about picking a better CMS — it was that a headless CMS's technical merits don't matter if the people using it daily can't work confidently without an engineer standing by.
