$15 a seat plus the build: what a Sanity and Astro content platform costs in 2026

Summary. Sanity's Free plan costs $0 forever with 20 seats, 10,000 documents and 2 public datasets. Growth costs $15 per seat per month, allows up to 50 seats, raises the document quota to 25,000 and unlocks private datasets. The three Growth add-ons are the numbers most buyers miss: increased quota at $299 per month, dedicated support at $799 per month, and extra datasets at $999 per dataset per month. Storyblok lists Growth at $99.00 a month with 5 seats and Growth Plus at $349.00 a month with 15 seats, with additional seats at $15.00 each. Those licence numbers are real, sourced and, for most companies, the least important line in the budget. The build dominates, and the single biggest lever on it is how many content types you agree to model before anyone writes code.

This is a costing guide, not a product review. It uses live vendor pricing as of July 2026, Astro 6's current capabilities, and Google's own published position on what an "AI-ready" content platform actually needs, which turns out to be less exotic than most agency pitches claim.

The licence line: what Sanity actually charges

Sanity publishes its self-serve pricing openly, which makes it easy to model. Prices are per month, self-serve plans are monthly only, and a seat is consumed by every user type except the Viewer role, which is free.

The Free plan's behaviour at the limit is the detail worth internalising. It has hard caps with no overages: when a project reaches its quota for documents, assets, API requests, API CDN requests or bandwidth, the relevant functionality is blocked. That is a fine constraint for a prototype and a bad one for a live marketing site with an unpredictable traffic month.

Growth swaps that cliff for a meter.

Then the add-ons, which are where a Growth bill stops looking like $15 a seat. Increased quota costs $299 per month and extends the included quotas to 50,000 documents, 5 million API CDN requests, 1 million API requests, 500GB of bandwidth and 500GB of assets. Dedicated support costs $799 per month for direct access to Sanity's support engineers. Extra datasets cost $999 per dataset per month and unlock up to two additional datasets. Add-ons are available on Growth projects and bill in the following cycle.

Enterprise pricing is listed as custom, and every Enterprise quota on the comparison table reads "Custom". Anyone quoting you a specific Sanity Enterprise figure is quoting a deal, not a price list.

How that compares to Storyblok

Storyblok is the closest self-serve comparison, because it also publishes real numbers rather than routing everything through sales.

The structural difference matters more than the headline. Sanity charges per seat with generous shared quotas; Storyblok bundles a small number of seats into a flat monthly fee with a hard seat ceiling per tier. A 12-person content team costs $180 a month on Sanity Growth. The same team does not fit on Storyblok Growth at all, which caps at 10 seats, so it lands on Growth Plus.

Run that in the other direction and the answer flips. A three-person team on Sanity Growth pays $45 a month; on Storyblok Growth it pays $99.00. Neither product is cheaper in general. The seat curve decides.

Contentful is the third name that comes up in every shortlist. It does not publish comparable self-serve figures, so any number you see attached to it in a comparison post is someone's negotiated contract, not a rate. Treat it as a sales-led purchase and budget for a procurement cycle rather than a credit card.

Astro 6 is the other half of the bill, and it is mostly free

The front end is where the running cost of a content platform is usually decided, because it determines how much compute you rent and how much of your CMS quota you actually burn.

Astro 6 shipped a refactor of the dev server and much of the build pipeline on top of Vite's Environment API, which lets the framework run your exact production runtime during development. That closes the class of bug where something works locally and breaks on Cloudflare Workers, Bun or Deno. The release also added a built-in Fonts API, a Content Security Policy API, and an experimental Rust compiler.

The feature that changes the cost model is Live Content Collections, now stable. Astro's content layer previously assumed content was fetched at build time; Live Content Collections fetch at request time through the same APIs with no rebuild step. Content updates when it is published rather than when a build finishes.

That is a direct hit on two recurring costs. Build minutes stop scaling with publishing frequency, which matters once a marketing team is shipping several times a day. And editors stop waiting on a pipeline, which is the complaint that kills adoption of a headless stack faster than any technical problem.

Astro's islands model is the other lever. A client island is an interactive component hydrated separately from the rest of the page; a server island renders its dynamic content separately. In practice that means a page ships almost no JavaScript except where a component genuinely needs it, which is the cheapest available route to a good Interaction to Next Paint score. Google's threshold for a good INP is 200 milliseconds or less, and anything above 500 milliseconds is poor.

What "AI-search-ready" actually requires, according to Google

This is where most content platform pitches go wrong, and it is worth being blunt about it because it is the difference between a useful budget and a wasted one.

Google published a guide to optimising for generative AI features on Search, and it spends a whole section on what you can ignore. The document states plainly: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add." On the file that half the industry has been shipping: "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in generative AI search."

What Google does ask for is unglamorous and almost entirely a platform concern: the page must be indexed and eligible to appear in Google Search with a snippet, content must be crawlable, JavaScript must not block content, page experience must be good, and duplicate content should be reduced. On markup quality the guide is relaxed in a way that surprises people: "While it's not required to have perfectly semantic HTML (the web in general is not valid HTML, and Google can understand it), it's generally a good idea to try to use semantic HTML when possible."

Google also resolves the terminology argument directly. From its guide: "From Google Search's perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO."

The two mechanisms that generative features run on are worth knowing when you design a content model. Retrieval-augmented generation, which Google also calls grounding, uses the core Search ranking systems to retrieve relevant, current pages from the index. Query fan-out generates a set of concurrent related queries to fetch additional results. Both consume ordinary indexed pages. Neither consumes a special file.

The practical read for a platform build: the money belongs in indexability, render behaviour, page speed and the depth of what you publish. We have written more on this in our guide to Google's AI search optimisation advice and specifically on whether llms.txt helps.

The honest cost model

Three lines, and the first one is the smallest.

Licences. For a mid-sized marketing team, Sanity Growth at $15 per seat with the $299 increased-quota add-on is the realistic steady state, so a 10-seat team lands near $449 a month before overages. Hosting an Astro site on a serverless edge platform is usually a low two-figure monthly cost until traffic is substantial, and static output keeps it that way.

Build. This is the line that decides the project, and it is dominated by content modelling rather than code. A single-brand marketing site with 8 to 12 content types, a design system, editor previews and one language typically runs 6 to 10 engineer-weeks plus design. Add a second locale and it is not 2x, it is roughly 1.3x, because the model has to carry localisation from the start. Add a migration from an existing WordPress or Drupal estate with more than a few hundred URLs and the redirect map, content transformation and QA can equal the build itself.

Run. Content operations, not servers. Someone has to own the schema, review new content types before they are added, and stop the model sprawling into 40 types that nobody can explain. Teams that skip this end up paying for it in the next replatform.

The pattern we see most often: a company budgets carefully for the CMS licence, then spends three times that on unplanned modelling churn in months two and three because the content types were agreed in a workshop rather than against real pages. Model against the twenty pages you actually have. The real cost is usually the migration, not the code.

Where a Sanity and Astro stack is the wrong answer

Two cases, stated plainly, because a service page that pretends its approach fits everyone is useless to a buyer.

If your team has no engineering capacity at all and needs to change page layouts without a developer, a headless stack will frustrate you. Astro's strength is that a developer controls the output; that is also the constraint.

If your content is genuinely simple, a handful of pages that change twice a year, the Free plan of almost anything will do and the build cost will never pay back. Headless economics work when publishing volume, multiple channels or multiple locales are real.

India-specific considerations

For Indian teams the licence maths differs from the global default in one specific way: seat-based pricing in dollars is a larger share of total cost when engineering is delivered locally. A 12-seat Sanity Growth subscription is $180 a month regardless of where the team sits, while the build effort behind it prices very differently. That pushes Indian teams toward doing more of the work in-house and fewer add-ons, which is a rational response to the currency mix rather than a compromise.

Data residency is the second consideration. If you are handling personal data of Indian users through forms, gated content or a customer portal attached to the platform, the Digital Personal Data Protection Act 2023 applies to that processing regardless of where the CMS stores its documents. We design content platforms aligned with DPDP requirements, which in practice means keeping personal data out of the CMS entirely and letting the CMS hold content, not customers. It is the simplest architecture to defend.

Third, performance for Indian traffic rewards the static-first approach more than it does in Europe or North America, because a larger share of sessions arrives on mid-range Android devices where JavaScript execution, not network time, is the bottleneck. Astro's islands model targets exactly that cost. If Core Web Vitals are the immediate problem rather than the CMS, our Core Web Vitals and web performance work is usually the faster route than a replatform.

How we build these

eCorpIT was founded in 2021 and works from Gurugram as a CMMI Level 5 certified, MSME certified organisation with senior-led, multi-disciplinary teams. We are partners with AWS, Microsoft, Google and Shopify.

Our engagement on a content platform runs in four stages. We start with a content audit against your live URLs, not a whiteboard, and produce the content model from what you actually publish. We then build the Sanity Studio, the Astro front end and the editor preview together, so writers see their own changes rather than a developer's approximation. Migration and redirects follow, with the redirect map treated as a deliverable rather than an afterthought. Finally we hand over with the schema documented and a rule for who may add a content type, which is the control that keeps the model from sprawling.

Typical first release is 6 to 10 engineer-weeks for a single-brand site, longer where a migration is involved. We work in your repository, and the stack is yours at the end of it.

FAQ

How eCorpIT can help

eCorpIT builds and migrates content platforms on Sanity and Astro for Indian and global clients, with senior engineering teams that own the content model, the front end and the migration rather than handing you a theme. We design these platforms aligned with Digital Personal Data Protection Act 2023 requirements and against Google's published technical guidance for search and generative AI features, not against GEO folklore. If you are choosing between a replatform and a performance fix, we will tell you which one your numbers support. Look at our custom web application development work or talk to our team.

References

1. Sanity, Pricing, accessed 23 July 2026.

1. Sanity Docs, Plans and payments.

1. Sanity, Introducing the new Sanity Growth plan to serve collaborative teams.

1. Storyblok, Pricing, accessed 23 July 2026.

1. Astro, Astro 6.0 release announcement.

1. Astro Docs, Islands architecture.

1. Astro, What's new in Astro, June 2026.

1. Google Search Central, Optimizing your website for generative AI features on Google Search.

1. Google Search Central, A new resource for optimizing for generative AI in Google Search, May 2026.

1. Google Search Central, AI features and your website.

1. Google Search Central, Search Essentials technical requirements.

1. Google Search Central, JavaScript SEO basics.

1. web.dev, Interaction to Next Paint (INP).

1. Google Search Central, Creating helpful, reliable, people-first content.

Last updated: 23 July 2026.