
Átila de Freitas
The Fastest Way to Destroy a Sanity Schema
Give some marketers edit access and walk away. I learned the hard way that a schema isn't a data model, it's a product, and its users are editors on a deadline. Here is what made the rebuilt one hold up.
The fastest way to destroy a Sanity schema? Give some marketers edit access and walk away.
I learned this the hard way.
I built a landing page schema I was proud of. Clean, flexible, simple. Then I handed the Studio over to a marketing team, people who'd only ever see the editing interface, never the schema behind it. Came back a month later.
The page was a mess.
Empty sections that shouldn't be there. A hero with three headlines stacked on top of each other. Fields left blank that quietly broke the layout. Someone had used a "quote" block to fake a button, because the real button was somewhere they couldn't find.
And here's the thing: they were right to. I'd built the schema for someone who thinks like me. Nobody in that Studio thinks like me. They think like marketers on a deadline, and my "clean" schema gave them just enough room to break the whole page.
So I rebuilt it around a different question. Not "what can this schema do?" but "what's the worst a well-meaning marketer can do to it?"
What actually made it future-proof
- Make bad states impossible, not just discouraged. If a section needs a title, the schema shouldn't let it publish without one. Validation isn't nagging. It's a safety net that saves everyone at 4:59 PM on a Friday.
- Hide the complexity they don't need. Show fields only when they matter. A marketer who picks a "video hero" shouldn't see eight image fields that do nothing.
- Name things for them, not for you. "CTA Button (shows bottom-right)" beats "ctaConfig." In the Studio, the field label is the whole interface. Write it like you're writing UI text.
- Give options instead of empty text boxes. Fixed choices over free text wherever the design has limits. Fewer ways to go off-brand. Fewer ways to break the grid.
- Give them a preview that matches the real page. If they can see what they're building as they build it, they stop guessing, and you stop getting Slack messages.
The mindset shift that changed everything for me
A schema isn't a data model. It's a product. And its users aren't developers. They're marketers living inside the Studio, who'll never see your code and shouldn't have to.
Build for the person editing at 5 PM on a deadline, not for the perfect page you see in your head.
How do you keep your CMS schemas from falling apart across a big content team? Curious what guardrails others use.