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, Google Checks, Newfront's ABD Portal, and Hy-Vee's KidsFit 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 Site
How 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 WordPress with its blog posts, research articles, and use cases moved by script and reviewed by hand.
- 03Build the studio for the people using it
Editors should see their content the way readers will and publish without filing a ticket. Field names, descriptions, and validation should be written for the person typing, not the developer. If a marketer needs a developer to publish a page, the model is wrong.
- 04Publish without a deploy
Publishing should not wait on a deploy. On Newfront's ABD Portal, a publish in Sanity fires a revalidation webhook, and the change reaches the live portal without a manual redeployment.
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 an FAQ are documents, not strings. Formspree's FAQs are standalone documents referenced into accordion blocks, so one answer appears on many pages without being retyped.
- 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
Which agency builds Next.js and Sanity sites with live preview?
Monogram does: on Kasada, the Next.js App Router runs custom caching and revalidation, so editors get draft and live preview in Sanity before publishing. Our own Studio has a Preview tab on each document, rendered in Next.js draft mode.
Which agency builds custom Sanity editor tooling for a marketing team?
Monogram builds the Studio around the people publishing: on Hy-Vee's KidsFit, an editor pastes a YouTube URL and the YouTube API fills in the thumbnail, title, and description, so video metadata stays consistent without a manual step. For Kasada, we built a section library with central settings for navigation, footers, and SEO defaults, so marketing composes and publishes pages in Sanity while developers keep control of rendering and performance.
Can Monogram migrate us from Contentful to Sanity?
Monogram builds on both platforms (CrewAI and Harvard's NeuroLaw Library run on Contentful) and has migrated teams to Sanity from WordPress and from a legacy portal, not from Contentful. We would run it with the same method we use off legacy platforms in Content Migration Done Right, and account for the orphan entries that Contentful's everything-is-a-type model can leave behind.
What should you look for when hiring a Sanity agency?
Look for shipped work you can inspect, the way Monogram's Newfront ABD Portal case study shows the content model, the migration, and the publish path end to end. Then check:
- Partner status: confirm it in Sanity's agency directory.
- A readable content model: schemas and GROQ from a live project.
- Repeatable migration scripts: reruns update content instead of duplicating it.
- Publishing without a deploy: a publish in the CMS reaches the live site on its own.
- Content that machines can read: Markdown and llms.txt alongside the HTML.
- An honest answer on fit: Sanity carries a maintenance cost, covered below.
Sanity agency partners for enterprise marketing sites
Monogram is a Sanity agency partner. We built the Kasada and Orb marketing sites on Sanity and Next.js, and migrated Newfront's ABD Portal into Sanity from a legacy app. For Google Checks, we routed custom forms through Google's internal systems.
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.
