cms // stack
Our default CMS: visual editing for marketing teams that ship without tickets.
Storyblok is our core CMS, mapped blok-for-blok to Astro components with visual preview and locale workflows. Editors compose pages visually while the frontend keeps its performance budgets.
Our core CMS — pair with Astro on every content site; reach for Sanity only when content is product-like.
why we use it
(01) Real visual preview
Editors click into the live page and edit in place. No mental mapping between form fields and the published layout.
(02) Locales without collisions
Per-locale publishing with fallback chains lets regional teams move independently without overwriting each other.
(03) Components, not pages
Bloks mirror Astro components, so new landing patterns arrive as composable blocks instead of developer requests.
scope
(01) Visual editor mapped to Astro components
(02) Locale workflows with fallback chains
(03) Component-level publishing and scheduling
(04) Typed blok contracts checked at build time
tradeoffs
Our default versus the common alternative, stated honestly.
| dimension | 2sh | traditional |
|---|---|---|
| Autonomy | Marketing composes pages without developer tickets | Every landing variant waits in the backlog |
| Locales | Regional teams publish independently with fallbacks | One global draft blocking every market |
| Guardrails | Allow-listed bloks keep pages on brand and on budget | Free-form builders shipping megabytes of embeds |
| When not Storyblok | Product-like, developer-shaped content may use Sanity as a supported alternative | Visual editing forced onto structured data problems |
Not sure Storyblok fits your estate?
In the audit we map your estate, model the cost of staying versus moving, and document the recommendation in writing.