cms // stack
Supported alternative: content as product data for developer-shaped estates.
Sanity stays in our supporting stack for product-like estates. We model Sanity schemas around your publishing workflow, with typed GROQ queries, live preview, and editorial roles — while Storyblok remains the default.
Supported alternative to our Storyblok core — use when content is product-like and developers shape the editing experience.
why we use it
(01) Structured, not blobs
Portable text, references, and validation rules turn pages into queryable data instead of HTML blobs pasted into textareas.
(02) Preview that matches production
Draft perspectives render in the real Astro templates, so editors approve what visitors actually see.
(03) Workflows that scale
Datasets, roles, and releases give multi-brand estates staging discipline without developer bottlenecks.
scope
(01) Typed schemas with validation and references
(02) GROQ queries fetching exactly what each template needs
(03) Live draft preview inside production Astro layouts
(04) Releases and roles for multi-brand publishing
tradeoffs
Our default versus the common alternative, stated honestly.
| dimension | 2sh | traditional |
|---|---|---|
| Modeling | Schemas designed around your publishing workflow | Generic fields bent around theme assumptions |
| Editor experience | Custom input components for repeatable patterns | Shortcodes memorized from a wiki page |
| Performance | Build-time fetches with surrogate-key invalidation | Per-request CMS calls on every page view |
| When not Sanity | Visual-first marketing teams belong on our Storyblok core | Forcing one CMS onto every team and locale |
Not sure Sanity fits your estate?
In the audit we map your estate, model the cost of staying versus moving, and document the recommendation in writing.