The case for Sanity as your first CMS

The CMS decision comes up on almost every project. Marketing team needs to update content. Blog needs to be edited without touching code. Case studies need adding. The question is always: where does that content live and who controls it?

We've built on WordPress, Contentful, Strapi, and a few others. For most projects we build now, the answer is Sanity. Here's why.

What GROQ changes

Most headless CMS products give you REST endpoints or GraphQL. You request a resource and get back a blob of data that includes everything — fields you need, fields you don't, nested references that you then have to traverse client-side.

Sanity uses GROQ, a query language built specifically for content. The difference in practice is that you specify exactly what you want in the query and get back exactly that. No over-fetching. No transforming a large API response into the shape your component needs.

// Get featured work items with only the fields the card needs
*[_type == "work" && featured == true] | order(order asc)[0...3] {
  _id,
  title,
  "slug": slug.current,
  type,
  year,
  description,
  "thumbnail": thumbnail.asset->url,
  tags
}

This query returns exactly the six fields the card component uses. The thumbnail is resolved inline — no second request. The slug is extracted from its nested object. The filtering and ordering happen on Sanity's infrastructure, not in your JavaScript.

The Studio

The editing experience matters. Content editors are not developers. If the CMS requires understanding data models or writing in front matter, they'll avoid using it and ask a developer to do it instead. That's expensive and slow.

Sanity Studio is configurable enough to give editors a clean, opinionated interface for each content type, and restrictive enough to prevent them from breaking things. You define the schema in TypeScript. The Studio generates the editing UI from it. Field validations, ordering controls, and reference pickers are all first-class.

The ability to embed Studio at /studio within the Next.js app — rather than sending clients to a separate admin subdomain — is a small thing that turns out to matter for adoption.

Where it adds overhead

Sanity is not a good choice when the content is static and unlikely to change. If you're building a portfolio with five projects that you'll update twice a year, a few MDX files are a better fit than standing up a CMS project.

The free tier is generous but the pricing scales based on API requests. For high-traffic content-heavy sites, that cost needs to be factored in.

The TypeScript SDK is excellent but the schema definition is verbose compared to something like Contentful's UI-based schema builder. For non-developers who want to own the CMS setup, that's a barrier.

The tradeoff in plain terms

Sanity costs more setup time upfront than other options. In exchange, you get precise queries, a configurable editing UI, real-time collaboration in Studio, an image CDN with transform parameters, and a webhooks system that integrates cleanly with Next.js ISR.

For most projects we build — where content will be updated regularly and the client needs to own that process — the setup cost is paid back within the first few edits.