3 Projects in Sanity, 3 Different Pricing Decisions: What Nobody Explains About Its Tiers
There’s one question that reaches me every week since I published my article about managing 12 languages in Sanity without duplicating pages: “When do I need to move to a paid tier?”
Short answer: later than you think if you’re building solo, sooner than you expect if you work with a team or have clients.
The long answer is this article.
I’ll walk you through three real scenarios, the reasoning behind each pricing decision, and the framework I now use to evaluate tiered tools. No fluff.
Why Sanity has the most honest free tier in the CMS ecosystem
Look, most free tiers are bait. They offer something useless to push you to upgrade fast. Sanity doesn’t work that way.
The free tier includes real projects: multiple datasets, full access to the content API (GROQ included), a customizable Sanity Studio, and enough admin users for a solo builder or a very small team.
What made me choose Sanity in 2026 over other headless alternatives is exactly this: you can build and ship a real product without paying anything. It’s not a sandbox. It’s production.
These complex queries with references and joins are available from day one, on any tier. That’s not trivial if you’re coming from other CMS platforms.
Project 1: My personal SaaS — Months in on the free tier
I have a content project where I’m the only editor. Blog, product documentation, marketing pages.
Decision: free tier. Without a second thought.
Why? Because Sanity’s free tier scales well for single-person projects. API limits are generous for real (not toy) traffic. And the customized Studio with my own schemas has been running in production since launch.
What I do is monitor usage from the dashboard. If I see I’m approaching API request limits, that’s the signal to evaluate an upgrade.
Project 1 takeaway: If you’re building solo and shipping a product, stay on the free tier until the limits naturally push you out. That moment will come organically.
Project 2: Client work — The moment the free tier fell short
Here things change.
A client needed their marketing team (three people) to access the Studio. Plus an external reviewer. Plus me as the developer managing the project.
Sanity’s free tier is generous with admin users, but when you start stacking differentiated roles (editor who can only publish posts, reviewer who can only read, admin who manages schemas), you need the Growth tier.
The Growth tier adds what actually matters in client environments:
→ Granular roles and permissions — define exactly what each user can do in the Studio
→ More datasets — useful for separate staging/production environments per project
→ Priority support — when the client calls at 9am with an error, you need a fast response
The decision was simple: granular permissions alone justify the upgrade on client projects. It’s not a luxury — it’s an operational requirement.
Project 2 takeaway: In client work, the Growth tier isn’t a cost, it’s an investment in never having awkward conversations about who deleted what content.
Project 3: Team content platform — The Enterprise case
This one is different. A platform where content is the product, with an editorial team of more than ten people, publishing across multiple brands and markets (including the GDPR implications that in Spain and Europe we simply can’t ignore).
Here the Enterprise tier makes sense for specific reasons:
→ Guaranteed SLA — you need availability commitments in a contract
→ Data residency in Europe — relevant for GDPR compliance when content includes user data
→ Dedicated support — not tickets, but an assigned person
→ Custom domains for the Studio — your Studio on your domain, not on sanity.io
European regulation is non-negotiable. GDPR requires knowing exactly where the data you process resides. Sanity’s Enterprise solves this with data residency options that lower tiers don’t offer with the same level of contractual control.
Project 3 takeaway: Enterprise is for when the CMS is critical infrastructure and you need legal and operational guarantees. Not before.
The framework I use to decide when to move up a tier
After these three projects, I have three clear questions:
1. How many people edit content and with what different roles?
- Just you → free tier
- Up to 3-4 people with the same access level → free tier holds up
- Differentiated roles (editor, reviewer, admin) → Growth
- Large team with European compliance → Enterprise
2. Is the CMS critical infrastructure for the client’s business?
- If a 2-hour outage is a minor problem → Growth
- If a 2-hour outage costs the client real money → Enterprise
3. Are there GDPR implications with the content?
- No personal data in the CMS → any tier
- Personal data from European users → evaluate Enterprise with European data residency
The conclusion nobody says out loud
Sanity is one of the few tools in the headless ecosystem where the free tier is honest enough to ship real things. In 2026, with the infrastructure costs we manage as independent builders, that matters.
But the key isn’t staying on the cheapest tier possible. It’s understanding exactly what you need and when.
I run projects across all three tiers simultaneously. Each one where it belongs.
Concrete action for this week:
If you have a project on Sanity, open the dashboard and check actual API usage over the last 30 days. If you’re below 60% of the free limit, you have nothing to do. If you’re above 80%, start evaluating Growth before you need it urgently.
Reactive infrastructure decisions always cost more than proactive ones.
