How to vet a senior Sanity CMS developer: a practical buyer's guide

Jul 04, 2026 · 6 min read

Knowing how to vet a senior Sanity CMS developer is harder than it sounds. The title 'senior' is self-applied on most freelance platforms, and Sanity's relatively young ecosystem means a lot of developers have built one or two projects and now market themselves as experts. This guide gives you a practical way to separate genuine seniority from surface-level familiarity — without needing to be a developer yourself.

What 'senior' actually means on the Sanity stack

Seniority on any CMS breaks into two distinct layers: the content modelling layer and the integration layer. A genuinely senior Sanity developer is strong in both.

The content modelling layer is Sanity-specific. It covers how schemas are structured, how documents reference each other, how editors actually experience the Studio day-to-day, and how data is queried. A developer who only knows how to follow Sanity's own tutorial has probably built a handful of fields and a basic page type. A senior developer has run into real problems — circular references, slow Studio loads caused by bloated document types, editors confused by poor field ordering — and has solved them more than once.

The integration layer is where Sanity connects to your front-end (almost always Next.js in 2026). Senior means the developer understands how content changes flow through to a live site without breaking pages mid-publish, how images are served efficiently, and how draft previews are secured. These are not beginner concerns. They become critical at scale and under real editorial pressure.

A candidate who speaks fluently about both layers — and can give you concrete examples from real projects — is demonstrating seniority. A candidate who speaks confidently about schemas but goes vague when you ask about delivery and performance is a mid-level developer at best.

Portfolio signals worth looking for

Ask to see two or three live projects built on Sanity. Then look for these specific signals, which you can verify yourself:

The Studio URL exists and works. A Sanity project ships with an editor interface. If a developer can only show you a front-end website and not the Studio, they may not have built the CMS side from scratch — they may have cloned a starter.

Images load fast and don't jump around. Open the site on a mobile connection if you can. Images should appear in the correct aspect ratio from the start, without layout shifting as they load. Getting this right requires deliberate technical decisions on the Sanity and Next.js side. If images pop in late or cause content to jump, that's a gap in their implementation.

The content structure makes editorial sense. Ask the developer to walk you through how an editor would create a new page or post. A senior developer will have built a Studio that guides editors rather than overwhelming them. If the schema walkthrough is confused or the Studio looks like a raw database, they haven't thought about the editor experience.

They can name a problem they solved. Ask directly: what was the hardest Sanity-specific problem you hit on this project? A senior developer will have a real answer — something specific about references, query performance, permissions, or preview behaviour. Vague answers like 'we had some challenges with the setup but resolved them' are a warning sign.

Questions that reveal genuine depth

You don't need to understand the technical details to evaluate the quality of the answers. You're listening for specificity and confidence.

'How do you handle content that editors need to preview before it goes live?' A senior developer will describe a secure preview mechanism and explain why security matters here. A junior will say 'Sanity has a preview feature' without explaining how they implemented it safely.

'How do you structure schemas when a page needs to share content blocks with other pages?' This is about reusability. A senior developer will talk about references and reusable document types. A junior will describe duplicating content across pages, which creates maintenance debt.

'What happens to the live site when you add a new field to an existing schema?' This question tests whether the developer thinks about your live environment, not just the development environment. A senior developer will explain how they handle schema changes without disrupting published content.

'How do you control which editors can edit which content?' Sanity has a permissions system. A senior developer has used it and can describe how they configured it for a real project. If the developer hasn't set this up before, your editorial team will have uncontrolled access to everything.

Red flags that are easy to miss

These patterns recur with developers who are competent enough to pass an initial conversation but aren't at the level you need.

They recommend Sanity for every situation without qualification. Senior developers know when Sanity is the right fit and when it isn't. Someone who pushes it regardless of your actual requirements is either not thinking critically or is invested in only one tool.

Their portfolio is all starter templates. Sanity's documentation includes several polished starters. A developer whose portfolio looks like variations of the same starter hasn't built a real content model from a client brief.

They can't explain how your editors will work day-to-day. If the developer hasn't spent time thinking about editorial experience — how editors navigate between pages, how they manage drafts, how they handle images — you'll inherit a Studio your team won't want to use.

They haven't worked within a budget or timeline constraint. This is a consulting skill, not just a technical one. Ask how they handle a situation where a feature request doesn't fit the timeline. Senior consultants have a process for this. Junior contractors often don't.

What a solid proposal signals

Before you engage anyone for a paid project, ask for a brief written proposal covering: how they'd structure your content model, how the editor workflow would work, and how the front-end would consume the content. A senior developer will ask clarifying questions before writing this. They'll also flag risks — content types that are unusually complex, integrations that might affect the timeline — rather than promising a smooth path.

The quality of this document tells you a lot. It doesn't need to be long. It needs to be specific to your project, not recycled from a template. A developer who sends a generic scope of work without referencing your actual requirements hasn't done the senior work of understanding the problem before proposing a solution.

Related posts

All posts ↗