The first time I pitched Sanity to a client, I lost the room for about ten minutes. There was no WYSIWYG editor. No familiar pages tree. No toolbar that looked like anything they'd seen before. The person across the table kept asking where the content was, and I kept explaining that the content was the point, that what we were building wasn't a website with a CMS bolted on, but a content platform that happened to power a website. That distinction matters more than most teams realise until they've spent two years maintaining the alternative.

I've been using Sanity on client work and my own projects long enough to have formed real opinions about where it earns its place and where it asks something difficult of you. The portfolio you're reading this on is built with Next.js and Sanity as the content layer. That's not a demo setup. It's a production stack, and that's deliberate.

The hidden tax on every other option

For most of its history, the CMS market offered two deals, and both had small print.

Self-hosted platforms like Craft, Umbraco, and old-school WordPress give you control. You own the infrastructure, the database, the upgrade path. In practice, that ownership compounds into a maintenance burden that grows quietly until it's eating a sprint every quarter. Security patches, PHP version incompatibilities, plugin conflicts on upgrade, server costs. The control was always real; the tax was just deferred.

Fully managed SaaS platforms like Contentful and Prismic in its more structured configurations flip the trade. No infrastructure, clean APIs, good documentation. But you're working within their content model, their field types, their pricing curve. The moment your editorial requirements get interesting, you're either bending the content model to fit the platform's constraints or paying for an enterprise tier to unlock the flexibility you needed from the start. The convenience is a rental agreement, and the landlord sets the terms.

What neither camp questioned was the assumption that the CMS and the frontend lived in different worlds, and that developers had to translate between them. Eurostar's switch away from a legacy PHP stack is a useful data point here: CMS development tasks that previously took two to three weeks dropped to two to three days. That's not a marginal improvement. It's the difference between a platform that moves with the team and one that resists it.

What Sanity actually bets on

Sanity's position is architecturally different, and once you see it, the other options look like they're solving the wrong problem.

The content lake, Sanity's hosted data layer, handles the infrastructure. Your data is stored, versioned, and served through APIs you don't have to build or maintain. That's the managed part. But the Studio, the editorial interface itself, is a React application that lives in your repository, versioned alongside your code, deployable wherever your frontend deploys. There's no hosted admin panel you log into on a subdomain. The CMS is part of your codebase.

That single decision cascades into everything. A frontend developer can build a custom input component for the Studio in an afternoon, using the same tools they use for everything else. Need a colour picker that enforces brand tokens? A rich text editor that knows about your component library? A media field that pulls licensed images directly from Unsplash without the editor leaving the Studio? These aren't feature requests you raise with a SaaS vendor. They're components you write. I've shipped the Unsplash integration on my own portfolio, and it took less time than configuring a comparable workflow in any managed platform I've used.

Then there's GROQ. Most developers encounter it and assume it's a proprietary query language bolted on for differentiation. It's actually a rethink of the query model itself. In SQL and most REST or GraphQL abstractions, you query against a table or a type and shape the response after the fact. GROQ inverts this: you query from the document outward, and projections let you define exactly the shape of the data you need at the point of querying. No over-fetching. No n+1 problems hiding inside a clean-looking abstraction. Independent developers who've used it in production consistently describe it as a productivity multiplier once the team is past the initial ramp — capable of joins, filters, and projections that would require multiple REST requests in other systems. The first time a frontend developer uses GROQ to pull a document with precisely the fields they need, in exactly the structure the component expects, it's one of those quiet moments where tooling stops feeling like a compromise.

The infrastructure underneath all of this is worth a mention, even if it's not the most exciting part. Sanity's API CDN caches content queries at the edge, meaning reads are fast globally without you configuring a caching layer. The asset pipeline handles images and files with the same approach. For teams serving multiple markets or multiple consumers from the same content source, that's meaningful. The performance infrastructure is just there.

One platform, multiple configurations

One thing that took me a while to articulate properly is that Sanity doesn't ask you to commit to an architectural style upfront. That flexibility is genuinely unusual, and it's worth being concrete about what it looks like in practice.

At the simpler end, a marketing website for a single product or brand maps naturally onto a page-based structure. You model pages, sections, reusable components. The schema is straightforward, the editorial experience is familiar, and Sanity performs well without asking anything exotic of the team. Even here, GROQ and the typed schema are already better than most alternatives, but the lift isn't high.

Move up in complexity to a team running both a web product and a mobile app from the same content source, and the content lake model starts earning its name in a different way. You model content once, articles, products, team members, whatever is relevant, and both consumers query it independently, shaping the response to their own needs through GROQ projections. There's no content duplication, no sync jobs, no risk of the app and the website drifting apart. The web team and the app team work from the same source of truth without coordinating on structure.

Push further into multi-brand or multi-market territory, a platform serving several distinct editorial experiences from a single shared content layer, and the architectural decisions made early start to compound visibly. PUMA is a useful example: a global sports brand that replaced independent regional CMSes with a single Sanity instance, shared across markets, with custom-tailored Studios for each team drawing from the same content lake. The result was over 500 landing pages, 55,000 pieces of reusable content, and a content platform that a single developer can deploy to any environment in five minutes. That kind of setup would be a bespoke engineering project on most platforms. In Sanity it becomes a modelling problem.

The point isn't that Sanity is the right choice across all three scenarios. It's that the same platform can accommodate all three without forcing you to choose a lane at the start and penalising you for changing it later.

The Studio is a platform, not a product

Most CMS products give you an interface and let you configure it. Sanity gives you a React application and lets you build with it. The distinction matters more than it might sound.

The custom dashboard is a direct expression of this. You're not choosing from a set of widgets or configuring a layout through a UI. You're composing React components that render whatever is most useful to your editorial team: recent drafts, publishing workflows, content health metrics, a view of what's scheduled for the week. I've built dashboards that surface things no off-the-shelf CMS would let you expose, because the dashboard is just code.

The plugin ecosystem extends this further. It's growing steadily, and the developer community around Sanity has the rare quality of being genuinely useful rather than just large. The Sanity team themselves are visible in it, which tends to keep the signal-to-noise ratio reasonable. Plugins aren't workarounds. They're first-class extensions of the same model the Studio itself is built on.

Then there's the collaboration layer, which in my experience is where editorial teams feel the difference most directly. Multiple editors can work on the same document simultaneously, with each other's presence visible in real time. Revision history is built in. The Presentation tool ties this together in a way that's worth describing precisely: it shows editors a live preview of their content rendered in the actual frontend, updating as they work, but it also surfaces where any given piece of content is used across the site. If you're editing a component that appears on fourteen pages, you can see that. That's content usage visibility, and it's something most CMSs handle badly or not at all. What's notable about how it was built is that it doesn't compromise the underlying architecture to deliver a visual editing experience. It composes on top of it. The foundation didn't change; a new capability was added without requiring a rethink of anything fundamental.

The AI dividend, and why it wasn't an accident

Content that's well-structured in Sanity turns out to be exactly what AI tooling wants to work with.

Most CMS content, even from platforms with good reputations for structure, ends up with fields that contain unstructured HTML, rich text blobs that carry implicit formatting decisions, and references that aren't consistently resolved. Feed that to a language model and you're doing cleanup work before you can do anything useful.

A well-modelled Sanity schema is typed, relational, and portable. Every field has a declared type. References between documents are explicit. There are no HTML blobs unless you deliberately reach for the rich text field, and even then, the portable text format Sanity uses is structured JSON, not serialised HTML. Teams that modelled their content carefully a few years ago got AI readiness largely for free. Teams that didn't are refactoring now. loveholidays built an AI translation pipeline on top of their Sanity content layer that cut their translation costs by 97% and reduced new market launch times from months to days. That outcome isn't available to teams whose content lives in unstructured blobs.

Sanity has also moved quickly on native AI integration. Connectors to the major language models are available directly as Studio plugins, meaning editors can work with AI-assisted content generation, summarisation, or translation inside the editorial environment without bolting on an external workflow. Having tested the AI connectors, the integration is direct enough to be genuinely useful rather than a checkbox feature. The connectors fit naturally because the architecture was always open. Adding them didn't require rethinking anything fundamental.

What it costs you

None of this is free, and it would be a disservice to make it sound like it is.

Schema design is architecture. The flexibility that makes Sanity powerful is the same flexibility that lets a team build a content model that's inconsistent, under-documented, and painful to extend six months in. Without someone treating content modelling as a genuine architectural decision, thinking through document types, reference patterns, naming conventions before the first field is written, you can end up with a schema that's harder to untangle than the constraints of a more rigid CMS would have been. The platform doesn't cause that problem, but it doesn't prevent it either. If there's no one on the team who's going to own that thinking, it's worth naming the risk before you start. And if developer turnover is high, that risk compounds: Sanity's schema-in-code model and GROQ queries carry institutional knowledge that's harder to transfer than a more standardised platform's configuration UI.

Editor experience also needs deliberate investment. Out of the box, Studio is sparse. Non-technical editors used to more polished managed platforms will find it clean but unfinished-feeling. Field groupings, validation messages, custom previews, input components that match the editorial team's actual mental model of the content: these need to be built. It's a consequence of the platform being a foundation rather than a finished product, not a flaw. Budget for it.

On choosing tools with a long view

I've been working with Sanity long enough to have watched it mature through several phases, from a tool that needed explaining to one that increasingly doesn't. That history gives me a perspective on it that I wouldn't have from starting recently, but the reasons I'd recommend it now are the same ones I'd have given in 2019.

The tools worth betting on are the ones with a coherent architectural position, not just a better feature list. Sanity was always explicit about where its responsibility ended and yours began. That clarity is what made the plugin ecosystem possible, what made the AI integrations fit naturally, what made the Presentation tool feel like an extension of the original idea rather than a pivot. A consistent bet, held over time, compounds into capabilities that would have been impossible to retrofit.

The question for any tool you're evaluating isn't whether it solves today's problem. It's whether the decisions baked into it are the kind that age well. Sanity's have.