Platform: Sanity
Sanity CMS development, starting with the content model
Sanity is only as good as the model behind it. We design the content structure first, then build the Studio and the front end around it.
In short
Sanity is a headless CMS that stores content as structured data and lets you build the editing screen, called the Studio, in code. It suits teams that publish the same content to a website, an app or search, and that want control over the editing experience. For a simple brochure site it is usually more than you need.
What Sanity is good at
Most CMS tools start with pages. Sanity starts with your content. A case study, a person, a product or a price table is a typed document with fields you define, and the website is one of several things that can read it. Editors get a screen built for your workflow, several people can edit the same document at once, and developers query exactly the fields a page needs.
That flexibility has a price. Someone has to model the content, build the Studio and wire the front end. If you only need a ten-page site that your marketing team edits visually, read headless vs traditional CMS before you commit. If you are weighing Sanity against another headless tool, see Sanity vs Contentful.
A worked content model
Here is how we would model a services company that publishes case studies, a team page and landing pages. The goal is that each fact lives in exactly one place.
| Document type | Key fields | Why it is separate |
|---|---|---|
| Service | Name, slug, summary, rich text body, related case studies | Appears on its own page, in menus and on landing pages |
| Case study | Client, industry, services used, outcomes list, gallery, quote reference | Reused on service pages, the home page and a filtered index |
| Person | Name, role, photo, short bio | Referenced by quotes and authors, edited once |
| Quote | Text, person reference, approved flag | Lets legal approve each quote separately |
| Landing page | Ordered list of blocks: hero, proof strip, form, FAQ | Marketing builds pages from blocks without developer help |
| Site settings | Navigation, footer links, default social image | A single place for global changes |
The approved flag on Quote is a small example of why this matters. A front end can refuse to show any quote that has not been approved, so nobody has to remember to check.
What we have built on it
We do not list a Sanity project on our work page, so this page does not claim one. The nearest projects are content-heavy builds: Asian Packaging has 67 products across styles, plies and flutes that had to stay easy to browse, and VK Magic sells single tricks, programs and props from one cart. Both show the kind of structured catalog where a typed content model pays off. We would be glad to scope the same approach on Sanity for your site through our headless Next.js service.
Gotchas we plan for
- Schema changes do not migrate old documents. Renaming a field in code leaves existing content under the old name. We write a small migration script and run it on a copy of the dataset first.
- Keep staging and production apart. Use separate datasets, each with its own tokens and allowed origins. A test import into the live dataset is hard to undo cleanly.
- The cached API and the live API differ. The cached endpoint is fast but can serve slightly old content. We use it for public pages and the live endpoint for editor preview.
- Query depth costs time. A query that follows references several levels deep gets slow on large datasets. We project only the fields a page shows and keep references shallow.
- Rich text needs a renderer. Sanity stores text as structured blocks, so the front end must say how to display each block, link and embed. Unhandled block types show up as blank gaps.
- Pin the API version. Sanity uses dated API versions. If you do not set one, behavior can drift when libraries update.
- Permissions are your job. Decide who may publish, who may only draft, and who can touch settings, before editors are invited.
Timeline
A typical Sanity project for a mid-sized marketing site runs 6 to 12 weeks. The model is the long pole, so the early weeks matter most. These are planning ranges, not promises.
| Weeks | Work | You review |
|---|---|---|
| 1 to 2 | Content audit, model workshop, first schema | The model on one page, with sample content |
| 2 to 4 | Studio build, roles, preview wiring | A working Studio with real entries |
| 3 to 8 | Front end templates and queries | Staging site fed from the Studio |
| 7 to 10 | Content import, redirects, search checks | Spot check of imported pages |
| 9 to 12 | Editor training, launch, monitoring | Final sign-off |
You get a fixed quote after a short call. Ask for a proposal.
Updated 30 October 2026
Questions, answered
Is Sanity better than WordPress?
Do I need developers to use Sanity every day?
Can you migrate our WordPress content into Sanity?
Will Sanity hurt our SEO?
What does it cost to run afterwards?
Keep exploring
Sanity vs Contentful: which to choose in 2026
Both store content as structured data and serve it to any front end. The difference is how much of the editing experience you get to shape.
ComparisonHeadless vs traditional CMS: the real difference
A traditional CMS manages content and builds the pages. A headless CMS manages content only and hands it to a separate front end. That split is…
PlatformNext.js development for sites that need speed and control
We build marketing sites, product front ends and web apps on Next.js when the project needs it, and say so plainly when it does not.
Modeling content for Sanity?
Send us your page list and we will propose a content model and a fixed quote after a short call.