Sanity is a hosted headless CMS with an unusually good editing interface — multiple people can work on the same document at once, and the editor is itself configurable. It suits editorial teams publishing continuously.
What is Sanity?
Sanity separates content from presentation like any headless CMS, but invests heavily in the authoring experience. Editing is collaborative in real time, in the way a shared document is, and the editing interface is itself code you configure rather than a fixed set of screens.
Its query language is genuinely good, which matters when a page needs a specific slice of content rather than everything.
The editing interface is defined in code, which is unusual and is the point. A field can validate against your own rules, a document can show a live preview of how it will render, and a reference to another record can display as something readable rather than an ID. That is configuration work, and it is why the authoring experience is better than a generic form.
When we choose Sanity
When several people publish continuously and collide. Real-time collaboration removes the "who has this open" problem that a lock-based CMS creates.
When the content model is complex and editors need an interface tailored to it rather than a generic form.
When we do not use Sanity
When data residency is a requirement — Sanity is hosted, and the data lives on their infrastructure.
When one person edits the site twice a month. The collaborative features are the reason to pay for it, and paying for them unused is a subscription with no return.
And when the budget is fixed and small. Configuring the editing interface properly is development time, and a Sanity project done badly — generic fields, no preview, no validation — is strictly worse than a simpler CMS done well.
What we build with Sanity
Editorial sites with a real publishing team
Where several writers and an editor work through a queue continuously, and the bottleneck is coordination rather than technology.
Publications with a daily cadence
Newsrooms and content teams where several people touch the same piece before it goes out. Real-time editing removes the version confusion that a check-out-and-lock system creates.
Structured campaign content
Landing pages assembled from approved, reusable blocks rather than free-form HTML, so a campaign page cannot end up off-brand and can be rebuilt for the next campaign in an hour.
Bilingual editorial workflows
English and Arabic versions of a document tracked against each other, so an editor can see at a glance what has been translated and what is still waiting.
Content operations for a marketing team
Scheduled publishing, embargoed announcements and a review step before anything goes live. The interface is configured around how the team already works rather than asking them to change their process to fit the tool.
How we ship Sanity projects
With the editing interface configured to the content model rather than left generic, since that is most of what you are paying for.
With preview wired up properly, and with the front end usually Next.js reading from it.
With validation rules on the fields that matter — a summary that must be under a certain length, an image that must have alt text in both languages, a publish date that cannot be in the past. Rules in the editor are what keep a site consistent once we are no longer the ones typing.
What Sanity costs you
Hosted, so data residency and vendor dependence both apply, and pricing scales with usage rather than being fixed.
Configuring the editing interface is development work, so the flexibility that makes it good also means it is not a thing you set up in an afternoon.
Its query language is powerful and unfamiliar — it is neither SQL nor GraphQL, so there is a learning curve for whoever maintains the front end afterwards. On a project with a long life and a rotating team, that is worth weighing against the better editing experience.
Sanity questions we get asked
Sanity if you have an editorial team publishing daily and collaboration is the bottleneck. A custom CMS if the site has a fixed content model, needs to be tightly bilingual, and the data should stay on your own infrastructure.
There is a free tier and pricing scales with users, documents and API traffic. For a small editorial team it is modest; for a large content estate it becomes a real recurring line. We model it against your actual volumes before recommending it over a self-hosted option.
Yes, the whole dataset exports as structured JSON, which is better than most hosted platforms manage. It is still a hosted service, so ask the data residency question at the start rather than after two years of content.
Sanity for the better authoring experience and real-time collaboration, if hosted is acceptable. Strapi when the data must stay on your own infrastructure. Both are reasonable; the residency question usually decides it before anything else does.
As many as you have — that is the feature you are paying for. Two writers and an editor can work in the same document simultaneously and see each other's cursors, which removes the "who has this checked out" negotiation that a lock-based CMS creates every publishing day.
Yes, because the schema is code. That is the trade for a tailored editing interface: adding a field is a small development task rather than a click. On a stable content model that is rarely a problem; on one still being figured out, it is a cost worth knowing about.
Yes, and Sanity is better at this than most headless systems — the preview can sit inside the editor next to the fields, updating as you type. It is still configuration work rather than something that arrives switched on, and we build it into the scope because editors judge a CMS almost entirely on this.
