← All articles

Sanity CMS in production: 6 months in, what we would redo and what not

04 March 20242 min read

Customizable Studio, GROQ, real-time collaboration. What sold us and the three places we sweated.

In September 2023 we shipped Sanity for a B2B services client wanting a multilingual site managed by 4 internal editors. Six months in, here is what works and where we bent.

What sold us

  • Studio: the editor is customizable in TypeScript. Not a visual builder hostile to devs — it is a React app you configure.
  • Typed schemas: declare the data model once, get auto-generated TS types on the frontend. No more CMS/code drift.
  • Real-time collaboration: two editors on the same doc see live edits. Notion-like, free out of the box.
  • GROQ: the query language is verbose but powerful, especially for joins and projections.

Where we sweated

1. Internationalization

Sanity has 3 i18n strategies: localized fields, separate documents, plugin. None is default. We tried all three before settling (localized fields for short text, separate documents for full pages).

2. Tiered pricing

The free tier covers a lot, but past 10 GB of assets or 10k API requests/month you enter Growth (99 USD/mo). We had to cache aggressively on Next.js (revalidate + tags) to keep the bill sane.

3. Studio embedding

Hosting the Studio inside the Next.js app (under /studio) looks elegant but complicates deploys: Studio builds are heavy and explode Vercel build times. We separated it into its own app with its own deploy.

Would we redo it?

Sanity yes, but only if the client has an editorial team using the site nearly daily. For projects where the CMS gets touched monthly, Markdown in repo or a simpler CMS (e.g. Decap) costs less and is plenty.