Stop Hiring Sanity Developers Based on GitHub Stars and Starter Templates

I spent three weeks debugging a Sanity setup last year that should have taken three days. The developer who built it knew the framework inside and out—could talk your ear off about schema optimization and GROQ queries. But when editors tried to create content, they'd get lost in a Studio that looked like a raw database with no guidance. The front-end was fast. The backend was elegant. The actual job it was supposed to do—let humans publish content—was broken.

That's when I realized: most of us hiring developers for CMS work are asking the wrong questions entirely. We're checking off technical boxes and ignoring the fact that a CMS only succeeds when the people using it every day don't hate it.

The Two Layers Nobody Talks About

Here's what took me too long to understand: being good at a CMS framework isn't one skill. It's actually two completely different competencies living in the same project.

The first is the modeling layer. This is the Sanity-specific stuff—how you structure schemas, how documents reference each other, how GROQ queries pull data. Most tutorials cover this. Most developers can recite it.

The second is the integration layer. This is about how content actually reaches users. How do you handle images so they don't cause layout shift? What happens when an editor publishes content while someone's viewing the page? How do you secure draft previews? How does a schema change in production without breaking live pages? This is where seniority actually lives, and it's also where most self-proclaimed "senior" developers go quiet.

The developer I mentioned earlier? Strong on layer one. Nearly absent on layer two. And I hired them without ever checking.

What I Should Have Asked

I'm more careful now. When I'm evaluating someone for a real Sanity project, I ask for two or three live projects and I actually look at them—not the marketing website, but the actual Studio the editors use every day.

Does it guide editors or overwhelm them? Is there a clear hierarchy? Can someone unfamiliar with the project figure out how to create a new page? If the developer can't walk me through the editor experience without getting defensive or vague, that's a warning. Content modeling isn't just a technical problem. It's a UX problem for the people doing the actual work.

I also ask about real problems. Specifically: what's the hardest Sanity thing you've actually solved? Not "we optimized performance"—what exactly did you do? Where was the bottleneck? Why was it happening? If they can't answer with concrete specifics, they probably haven't built at scale.

The questions themselves matter too. Ask how they handle permissions. Ask what happens to the live site when you add a field to an existing schema. Ask how they prevent circular references from tanking Studio performance. These aren't gotcha questions. They're proof that someone has shipped real work under real constraints.

Where I Disagree (Slightly)

The original article nails most of this, but I think it undersells one thing: consultancy as part of seniority. A genuinely senior developer doesn't just build technically correct solutions. They push back when a requirement doesn't fit the timeline. They suggest alternatives when Sanity genuinely isn't the best tool. They think about your constraints, not just the technical problem.

I've worked with developers who are brilliant technicians but can't navigate the reality of a real project—budget limits, stakeholder changes, scope creep. And I've worked with developers who are slightly less technically talented but deeply thoughtful about trade-offs. The second group made better decisions.

The Real Test

Here's what I do now before hiring: I ask to see a project. I use the Studio myself for ten minutes. I try to create a piece of content. If I'm confused, the editors will be confused. If something feels clunky, it wasn't an oversight—it was a choice the developer made and I'm about to inherit that choice.

Then I ask: why did you structure it this way? If the answer is "that's how the starter template does it," we're done. If the answer shows genuine thinking about editorial workflow, we talk more.

What about you?

Are you hiring for a Sanity project? Or have you been the developer getting questions about your work? What's the one thing you wish clients actually asked about?

Source: This post was inspired by "How to vet a senior Sanity CMS developer: a practical buyer's guide" by Dev.to. Read the original article