Sanity CMS development
We set up Sanity when content is reused across channels or a site is built in code and still has to be run by editors. We design the schema from what the site renders, organise the Studio around your team and connect publishing to the site build, with content you can always export.
- Schema designed from the pages
- A Studio organised for your team
- Publishing that rebuilds the site
- Images through the Sanity CDN
- Imports that never overwrite edits
Trusted by B2B and premium service brands in 17+ countries.
When we use it
When Sanity is the right choice, and when it is not
We choose Sanity when
- Content reused across channelsWhen the same products, articles or locations feed a website, an app and other tools, Sanity stores them once as structured data that every channel can query.
- Code-built sites that editors runBehind an Astro or Next.js site, Sanity gives editors a proper editing environment so content changes never need a developer.
- Content models that do not fit a builderReferences between many types, reusable blocks and rich text stored as Portable Text, modelled exactly as the business works rather than fitted into fixed collections.
We choose something else when
- A site built in Framer or WebflowBoth have their own CMS. Adding Sanity behind a builder adds cost and moving parts that a marketing site rarely needs.
Very small sitesA site with a handful of pages and no regular publishing does not justify a headless CMS.
Files in the repository or a builder are simpler.
- Editors who expect a page builderSanity edits structured fields, not freeform layouts. Teams who want to drag sections around a page are better served by a visual builder.
How we build
How we build with Sanity
Step 01
Schema designed from the pages
We model document types from what the site actually renders, field for field, with validation and descriptions that tell editors what each field is for.
Step 02
A Studio organised for your team
Desk structure grouped the way your team thinks about content: pages, collections, settings, so editors find things without knowing the schema.
Step 03
Publishing that rebuilds the site
A GROQ-filtered webhook triggers the site build on publish, so changes go live without anyone touching hosting.
Step 04
Images through the Sanity CDN
Editors set crop and hotspot in the Studio, and images are transformed through URL parameters and optimised for each layout.
Step 05
Imports that never overwrite edits
Content moved from an old site is imported with fixed document ids and additive writes, so a re-run never overwrites what editors changed in the Studio.
Ownership
What your team owns afterwards
The Sanity project is in your organisation, with your team as administrators. Editors publish without developers, roles control who can do what (the roles available depend on your Sanity plan), and the schema lives in your repository next to the site. Content can be exported at any time with the Sanity CLI, so it is never trapped.
Performance and SEO
Sanity does not render pages itself, so speed comes from the front end. With Astro or a statically rendered Next.js site, content is fetched at build time and served as HTML, so visitors never wait on the CMS. SEO fields live in the schema, which makes titles, descriptions and share images editable per document.
Pairs well with
What we pair Sanity with
Astro
For content-led sites: Astro reads Sanity at build time and ships static HTML.The official @sanity/astro integration is maintained by the Sanity team.
Next.js
For sites with an application side, with Visual Editing support through Sanity's Presentation tool so editors see changes on the page.
Common questions
Sanity development questions
Is Sanity hard for editors to use?
Not when the Studio is set up well. We group documents the way your team thinks, describe every field and hide technical ones, so editors see forms rather than a database.
Can we move our content out of Sanity later?
Yes. The Sanity CLI exports a dataset as a file, and the content is structured data rather than page markup, so it can be imported elsewhere.
Do we need Sanity for a Framer site?
Usually not. Framer has its own CMS, which suits most marketing sites. Sanity makes sense when the site is built in code or the content feeds more than one channel.
Next step
Considering Sanity? We will tell you honestly whether it fits.
We agree the architecture before any code is written, build in reviewable stages on staging, then test, deploy and hand over with the documentation your team needs.
- Architecture firstScope and structure agreed before any code.
- Built in reviewable stagesWorking pages on staging as the build moves.
- Handed over properlyDeployment, documentation and handover notes.
Considering Sanity for your next build?
Tell us what the site or product needs to do, and we will tell you honestly whether Sanity fits, before anything starts.