The CMS decision is one of the most consequential choices in a web project. It shapes how the site is built, how it performs, and how the people who manage it day to day actually experience it. It's also one of the decisions most often made by default rather than by design. This is how we think about it, and why headless is the right choice for the kind of work we do.

Whatheadlessactuallymeans
A traditional CMS like WordPress combines two things that are better kept separate: the codebase that powers the frontend, and the system that stores and manages content. They're bound together, which means each one carries the weight of the other.
A headless CMS separates them. The content lives in one place, the frontend lives in another, and the two talk to each other via an API. The result is a codebase that isn't constrained by the CMS, and a CMS that isn't carrying anything it doesn't need to.
This distinction matters more than it might initially seem.

Theproblemwithcoupledsystems
WordPress is a mature, capable platform and can be the right choice for plenty of projects. For large publishing operations, complex role-based teams, or users with deep WordPress expertise, it might be the best choice.
But for the kind of design-led marketing sites we build, the coupled approach creates friction that shows up in ways that are hard to unpick later.
The most visible version of that friction is in the editing experience. WordPress is built to serve a huge range of use cases, which means the editor interface has to accommodate all of them. The result is an environment full of options, settings, and buttons that have nothing to do with the site you're actually managing. Clients open the CMS and don't know what they should or shouldn't touch. Pages and features exist that were never part of the project. The interface doesn't reflect the site.
That's not a small thing. The CMS is where the client lives after the project ends. If it's confusing, content doesn't get updated. If it's cluttered, mistakes get made. The quality of the editorial experience is part of the quality of the product.
The other issue is on the build side. When the frontend and the CMS are coupled, the architecture of one constrains the other. The flexibility that a component-based, design-led site requires is harder to achieve when you're working within a system that wasn't designed for it.
Whyheadlessworksforthiskindofsite
Separating the frontend from the content layer removes those constraints in both directions.
On the build side, we're working with a clean codebase. The frontend is built exactly as the design requires, without having to accommodate the assumptions of a coupled CMS. Component architecture, custom interactions, performance optimisation: none of these are fighting against a system that wasn't designed for them.
On the content side, we can build an editing experience that reflects the actual site. The fields, the structure, the interface: all of it is set up for the specific content model of this project, not a generic one-size-fits-all environment. Editors see what they need and nothing they don't.
We always build with the end user in mind. The client's content team shouldn't need a manual to update their own website. A well-configured headless CMS makes that possible in a way that a traditional platform rarely does.
WhyweuseSanity
We've worked across a range of headless CMS platforms. Contentful, DatoCMS, Storyblok, Payload, Craft: each one has its strengths and there are projects where they're the right fit. But for the content-heavy, design-led marketing sites that make up most of our work, Sanity gets the balance right.
The content modelling is flexible enough to match a component-based architecture directly. The editing experience is clean and genuinely intuitive for non-technical users. The querying is powerful. And the pricing is honest for the kind of projects we're working on.
It's also a platform we know well, which matters. A CMS recommendation that comes from familiarity with a single tool isn't a recommendation, it's a default. Sanity is our go-to because we've worked with the alternatives and it consistently performs better for this type of work.
Beyondlaunch
The clients we work with are typically non-technical marketing teams. They need a CMS that's intuitive, reliable, and built around how they actually work. Headless gives us the flexibility to configure exactly that: a clean editing environment with no unnecessary complexity, a structure that can grow with the business, and a stable, secure foundation that doesn't need constant maintenance. It's the right tool for this kind of site, and the results bear that out.