Headless doesn’t have to mean hostile
There’s a version of headless CMS that gets sold as the dream and delivered as the opposite. Flexible architecture. API-first. Scalable. Future-proof. All true. Then your content team sits down on day one and stares at a blank JSON structure with no context, no previews, and no obvious way to just publish a page.
The technology is sound. The implementation lets people down.
WordPress became the world’s most-used CMS for a reason, and it’s not raw power or elegance. It’s that it understood its audience. Marketers could use it on day one. Pages looked like pages. Buttons did what the labels said. That’s the bar, and it’s higher than it looks.
What we actually build when we build in Sanity
Sanity is not WordPress, and it’s not trying to be. But the editing experience is entirely in our hands, and that’s exactly the point. When we set up a Sanity environment, we don’t hand over a default interface and call it done. We design the studio around the people who’ll live in it. That means:
Content types that speak your language, not developer language. A “Campaign Page,” not a “document.”
Fields that make sense in context, and validation that guides instead of blocking.
Previews that show editors what a page will actually look like before they hit publish.
Workflows mapped to real roles and real processes, not something a developer sketched out at 11pm before go-live.
An interface a new team member can navigate without a 45-minute onboarding session and a cheat sheet.
We don’t hand editors a blank canvas and call it flexible. We hand them a studio built for how they actually work.
Maya De PraeterSales Executive
The usability of WordPress, the power of headless
Here’s the thing about WordPress nostalgia: it’s rarely about WordPress itself. It’s about feeling in control. Knowing where things are. Being able to do your job without pinging a developer every time you want to change a headline. Sanity, built right, gives you that. And then some.
Because underneath the familiar interface, you’ve still got the full headless stack: multichannel publishing, structured content that feeds any front-end or platform, a content model that survives a website redesign, and performance your developers can actually work with.
You don’t have to choose between a CMS your editors love and infrastructure your developers trust. That’s the whole point.
“Built right” is doing a lot of work in that sentence
We’ll be honest: Sanity built badly is just as frustrating as any other badly implemented tool. The flexibility that makes it powerful is the same flexibility that makes it easy to get wrong. The difference is intent. Are you setting up a headless CMS for the people who’ll use it every day, or because headless was in the brief and the deadline was tight?
We start with the editors, every time. What do they publish? How often? What decisions do they make? What drives them mad about their current setup? That conversation shapes the content model, the interface, the workflow, and the rollout.
The result is a CMS that doesn’t need defending in a quarterly review. One your marketing manager would choose over WordPress, not grudgingly accept instead of it.
Maya's takeaway
If someone on your team has said “I miss WordPress,” that’s not a technology problem. It’s a signal that the implementation didn’t put people first. The good news: it’s fixable. Get the foundation right, and you end up with something better than WordPress ever was.
If you’re not sure whether your current setup is working for your editors, or you’re scoping a new one, that’s exactly the conversation we like to start with. Let’s talk.
Book a call with us