Sanity pricing: should we start on Free or go straight to Growth for a small team?

For a small team, the right Sanity pricing choice comes down to when you need guarantees, governance, and support—not just more features. You can comfortably start on Free to validate your content model and integration, then move to Growth once your content operations become business‑critical.

Quick Answer: If you’re a small team in build/validation mode, start on Free and design your content system properly. Move to Growth as soon as your Sanity project becomes production-critical, you need SSO and stronger governance, or you expect non‑technical editors to rely on it day‑to‑day.

Frequently Asked Questions

How do I decide between Sanity Free and Growth for a small team?

Short Answer: Start on Free if you’re designing, prototyping, or running a low‑risk project; choose Growth if your content is business‑critical, you need collaboration and governance, or want formal support and SLAs.

Expanded Explanation:
Sanity’s Free plan is built for developers and small teams who want to model content-as-data, set up Sanity Studio, and connect a few applications without worrying about upfront cost. You get the full “content operating system” primitives—Content Lake, schema-as-code, GROQ queries, real-time APIs, and Studio configuration—so you can design your content model and wire it to web, mobile, or internal tools.

Growth is for teams that have already proven the model and now care about operational reliability: stricter limits, higher usage ceilings, SSO/SCIM, stronger analytics, dedicated support, and governance. If your marketing site, product catalog, or internal tools would cause real pain if they went down or slowed, Growth is usually the responsible floor—even for a small team.

Key Takeaways:

• Use Free to design your schema, wire up your stack, and validate your approach without budget friction.
• Move to Growth once Sanity is on your critical path (customer-facing, executive visibility, or many non‑technical editors).

---

What’s the best process to start on Free, then upgrade to Growth later?

Short Answer: Treat Free as your design and validation environment: model schemas, connect your app, run tests—then upgrade the existing project to Growth when you’re ready for production.

Expanded Explanation:
Sanity’s plans are applied at the project/account level, so you don’t need to rebuild when you move from Free to Growth. The practical pattern is:

1. Use Free to model your content as JSON documents with schema-as-code, implement Sanity Studio, and connect your apps via one API.
2. Load sample or real content, test your workflows, and validate performance and usage.
3. As soon as you see that the project is moving from “experiment” to “core system,” upgrade the plan for that project to Growth and keep all your data, schemas, and integrations intact.

From a developer perspective, the CLI command (npm create sanity@latest), your Studio config, and your deployed frontends remain the same. You’re just changing the operational envelope: limits, guarantees, and support.

Steps:

1. Create a project on Free
   • Run npm create sanity@latest and initialize a Studio connected to a Free project.
2. Design & validate on Free
   • Define schemas with defineType/defineField, wire your frontend (Next.js, Remix, etc.), and measure usage.
3. Upgrade in place
   • Once happy with performance and risk profile, upgrade that project to Growth through the Sanity management UI—no schema or data migration required.

---

What are the main differences between Free and Growth for a small team?

Short Answer: Free gives you the full “content-as-data” model with lower limits and no formal guarantees; Growth adds higher ceilings, collaboration and governance features, and enterprise‑grade reliability and support.

Expanded Explanation:
Both plans give you the same core primitives: Content Lake, GROQ, real-time APIs, and a fully configurable Studio. The differences are about scale, safeguards, and support.

Free is optimized for exploration: low friction, generous but bounded limits, and enough capacity to power prototypes and smaller sites. Growth assumes you’re running production workloads and adds operational guarantees (uptime SLAs), stronger security and compliance posture, and support options that matter when a business depends on your content.

Comparison Snapshot:

• Option A: Free
  • Best for proving out schemas, building MVPs, side projects, and low‑risk internal tools.
• Option B: Growth
  • Best for production workloads where downtime or rate limiting would hurt customers or internal operations.
• Best for:
  • Start on Free if you’re still exploring your content model and overall stack.
  • Go straight to Growth if you already know Sanity will be a core system (e.g., global marketing site, product catalog, or internal knowledge layer used by many stakeholders).

---

How would a small team actually implement Sanity differently on Free vs Growth?

Short Answer: You implement Sanity the same way—schemas as code, Studio configuration, and one API—but on Growth you lean harder into collaboration, governance, and automation because you have the operational headroom to support them.

Expanded Explanation:
From an implementation standpoint, Free and Growth use the same code and mental model:

• You define your content schema in code (usually TypeScript) inside your Studio repo:

  import {defineType, defineField} from 'sanity'
  
  export const article = defineType({
    name: 'article',
    type: 'document',
    title: 'Article',
    fields: [
      defineField({
        name: 'title',
        type: 'string',
      }),
      defineField({
        name: 'slug',
        type: 'slug',
        options: {source: 'title'},
      }),
      defineField({
        name: 'body',
        type: 'array',
        of: [{type: 'block'}],
      }),
    ],
  })
  

• You run and customize Sanity Studio (using Vite under the hood) alongside your main app.
• You query Content Lake with GROQ from your web/mobile apps, or from agents and internal tools.

On Growth, you typically:

• Add stricter roles and permissions so content teams can operate safely.
• Introduce workflows like content releases, review steps, and preview-in-context.
• Start using automation (Sanity Functions, Agent Actions) triggered by document mutations to sync with downstream systems or perform schema‑aware enrichment.

What You Need:

• For Free:
  • A repo for your Studio configuration (schemas, plugins, desk structure).
  • A frontend (Next.js, Remix, etc.) that reads content from Content Lake via the API.
• For Growth:
  • All of the above, plus configured roles/permissions, observability for usage, and (optionally) Functions/Agent Actions for event‑driven automation.

---

Strategically, when is it smarter to skip Free and go straight to Growth?

Short Answer: Go straight to Growth if Sanity is clearly going to sit at the center of your content operations from day one—multiple brands, many editors, or mission‑critical experiences where you cannot risk hitting limits or lacking support.

Expanded Explanation:
For a lot of small teams, Free is the right first step. But there are scenarios where Growth is the more strategic choice even if you’re only a handful of people:

• You’re consolidating content from multiple systems into a single governed knowledge layer that will power many touchpoints (web, mobile, internal agents).
• Your marketing or product team expects to self‑serve content updates without involving developers, and you want guardrails (roles, review flows, auditability).
• Leadership expects reliability, compliance, and support that match the rest of your stack.

In those cases, the incremental cost of Growth buys you operational confidence: you can design schemas and automation once, then let the content team own 90% of updates without involving engineers, all backed by >99.95% uptime, 24/7 support, and compliance standards like SOC 2 Type II, GDPR, and CCPA.

Why It Matters:

• Reduced operational risk: You avoid last‑minute plan upgrades caused by hitting limits right as you launch or scale.
• Faster content velocity: Editors can own content changes with confidence, while developers focus on modeling, automation, and new features—not firefighting.

---

Quick Recap

A small team doesn’t have to “get pricing perfect” on day one with Sanity. Start on Free to design your schema-as-code, stand up Sanity Studio, and connect your first applications. As soon as your project becomes business‑critical—customer‑facing, multi‑stakeholder, or automation‑heavy—upgrade that same project to Growth to get higher limits, stronger governance, and support that matches how important your content operations have become. The implementation stays the same; you’re simply widening the operational envelope so your team can move quickly without outgrowing the platform.

Next Step

Get Started