Sanity, and the editor experience you inherit
Partner
Sanity gives you a content lake and a studio you compile yourself. That is the whole trade: nothing is decided for you, so every decision is yours to get right.
We build marketing sites and internal tools on Sanity with Next.js on Vercel, and we migrate teams onto it from legacy systems without stranding their archive. Kasada, Orb, Contextual AI, Zenity, Hy-Vee, and Newfront all run on it. This page is about how we model content, what we refuse to put in the CMS, and what a migration involves.
Visit Partner SiteHow we build
Model first, migrate second, ship third
- 01Model the content, not the page
Schemas describe what a thing is, not where it sits. A case study is a case study whether it renders as a card, a hero, or an entry in a filtered index. Page-shaped schemas are the reason CMS rebuilds happen.
- 02Map the archive before exporting it
Migration is a mapping problem. We audit the legacy content, decide what carries over, what gets rewritten, and what dies, and only then move it. Contextual AI came off a legacy system with its content intact and a model that could hold what came next.
- 03Build the studio for the people using it
Custom input components, previews, and structure so an editor sees their content the way readers will. If a marketer needs a developer to publish a page, the model is wrong.
- 04Ship on Next.js and Vercel
Server components read from Sanity directly, with on-demand revalidation on publish. Editors see changes without a rebuild, and readers get static performance.
The grain
Working with Sanity, not against it
- Don't model pages
Model content types and compose pages from them. The moment a schema is named after a URL, every new layout means a new schema.
- Don't put layout in the CMS
Editors need control over sequence and emphasis, not over spacing and color. A design system with a fixed set of blocks gives them the first without handing them the second.
- References are the point
An author, a client, a technology, and a sector are documents, not strings. Kasada, Orb, and Contextual AI all get filtered, cross-linked, and re-surfaced because those relationships were modeled as references from the start.
- Portable Text is not HTML
Store structure, render it per surface. The same body renders on a web page, in a feed, and to a machine reader without a second copy going stale.
- GROQ rewards a good model and punishes a bad one
A query that needs three nested joins to render a card is telling you the schema is wrong. Fix it upstream rather than in the query.
- Machines read this content too
Kasada needed a site that served enterprise buyers and intelligent machine consumers alike. Structured content, clean references, and machine-readable markup are what make that possible, and they come from the model, not from a plugin.
In production
What we build on Sanity
Sanity projects
Projects built on Sanity
More work
Other projects using Sanity
Sanity is the right call when the content has structure worth keeping and a team that will use it. It is the wrong call when the appeal is a studio with nothing to maintain: a customized Studio is a real frontend app, with dependencies and upgrades of its own, a maintenance surface the hosted competitors do not hand you.
Where it wins is the site that has to stay accurate for years: a model that holds, an archive that survives the next redesign, and content clean enough that both a reader and a machine can parse it. Monogram is a Sanity partner agency. Start a conversation.



