How to Hire a Sanity CMS Developer: Skills, Red Flags & What to Ask

Most Sanity CMS projects fail quietly. The site ships, the client is happy, and then six months later an editor tries to change a headline and can't find the field, or a GROQ query starts timing out as content volume grows, or a new developer opens the Studio and has no idea what the content model is supposed to do. Almost always, the root cause is the same: the person who built it was not a Sanity specialist. They were a React developer who had used Sanity once or twice and learned as they went.

Hiring the right person upfront is worth the extra effort. This is exactly how to do it.

The difference between a React developer who knows Sanity and a Sanity specialist

The distinction is not about years of experience — it is about depth on the specific things Sanity requires.

GROQ. Sanity's query language is not GraphQL and is not REST. A specialist writes GROQ queries that dereference references inline, filter conditionally, project exactly the fields they need, and avoid the waterfall patterns that make headless sites slow. A generalist knows how to copy a GROQ query from a tutorial and modify it slightly.

Schema design. A Sanity schema is more than a list of fields. A specialist designs reference relationships that editors can navigate intuitively, writes validation rules that catch bad data at publish time, and structures portable text blocks in a way that the frontend can reliably serialise. A generalist creates the fields they need and leaves the rest to the editor to figure out.

Studio customisation. Most real Sanity projects require some Structure Builder configuration, at minimum. Many require custom document actions, bespoke input components, or custom desk panes. A specialist knows the Studio plugin architecture. A generalist uses defaults.

TypeGen and type safety. Sanity TypeGen generates TypeScript types inferred from your GROQ queries, so a schema change surfaces a type error before deployment. A specialist uses TypeGen. A generalist either skips types entirely or hand-writes them against the schema — both of which break silently when the schema changes.

Webhook-driven ISR. On-demand ISR with revalidateTag is the correct pattern for Sanity content updates in a Next.js App Router project. A specialist has wired this before. A generalist often implements a workaround (full static rebuild, short TTL) that either makes the site slow to update or expensive to run.

The skills checklist

Use this to evaluate a portfolio, a CV, or a scoping conversation.

Must-have for any Sanity engagement:

• GROQ — can write joins, conditionals, and projections without documentation
• Next.js App Router — App Router data fetching with fetch, RSC patterns, draft mode
• Schema design — typed references, validation rules, portable text
• @sanity/image-url and the Sanity image CDN pipeline

Should-have for a real build:

• Sanity TypeGen — generates types from GROQ queries
• Sanity Studio Structure Builder — custom document ordering and grouping
• Webhook-driven ISR — revalidateTag wired to a Sanity webhook
• Portable Text serialisation — PortableText component with custom block types

Nice-to-have (signals depth):

• Custom document actions — approval gates, Slack notifications, schedule triggers
• Sanity Releases API — scheduled publishing
• Document internationalisation (@sanity/document-internationalization)
• Sanity Agent Actions — automated AI-driven field generation
• Mux + Sanity video pipeline

If a developer has fewer than five items from the must-have and should-have lists, they are a generalist who knows Sanity exists, not a specialist who has shipped it in production.

Where to find Sanity CMS developers

Sanity Experts directory. sanity.io/experts lists vetted Sanity developers and agencies. The listing includes portfolio work on Sanity specifically, which saves you the filtering step.

Upwork. Search for "Sanity CMS" (not just "headless CMS") and filter for job success scores above 90%. Read their project descriptions — look for mentions of GROQ, TypeGen, Studio customisation, and Next.js App Router rather than generic "headless CMS experience."

GitHub. Search for developers who have public Sanity schemas, GROQ query files, or Sanity Studio plugins. Real code is harder to fake than a keyword on a CV.

Direct referral. Ask other founders in your network who have shipped headless sites on Sanity. A good referral collapses the vetting process — you skip the portfolio review and go straight to a scope call.

Generic job boards. Less reliable for Sanity-specific work. LinkedIn and Indeed return generalists who have added Sanity to a keyword list. Use them as a last resort, not a first step.

What to ask in a scoping call or written brief

These five questions separate Sanity specialists from generalists. Ask them in any format — a call, a written brief, or a Loom request. Listen (or read) for specifics.

1. Show me a GROQ query you wrote for a project — what problem were you solving?

A specialist names the project type, explains what they were querying (references, conditionals, projections), and can explain why GROQ was a better fit than REST for that particular join. A generalist either cites a tutorial example or says "I used GROQ to fetch data from Sanity."

2. How do you handle ISR revalidation when a Sanity document changes?

Expected answer: Sanity webhook → Next.js route handler that verifies the signature → revalidateTag with a tag tied to the document type or ID. A generalist says "I used short cache TTLs" or "I set up a cron rebuild."

3. Walk me through a schema you designed — how did you decide on the reference structure?

A specialist explains a real content model: why certain fields are references vs inline arrays, how they handled circular references, what validation rules they added. A generalist describes a flat schema with a handful of fields.

4. What Sanity Studio customisation have you shipped in production?

Minimum expected: Structure Builder with custom document ordering. Better: a custom document action or a custom input component. A generalist says "I used the default Studio."

5. How do you handle Portable Text serialisation for a custom block type?

A specialist explains the PortableText component and custom components prop — specifically how they handle custom marks, annotations, or inline objects. A generalist says "I rendered the HTML" or does not know what Portable Text is.

Red flags in portfolios

Sanity mentioned but not described. A portfolio that lists "Sanity CMS" under technologies but never describes a schema decision, a GROQ query, or a Studio configuration is a generalist covering their bases.

Only tutorial-level projects. Blog sites with a posts schema and a basic GROQ fetch are tutorial-level. A specialist has shipped content platforms, migrations, or custom Studio tools.

No TypeScript in Sanity work. A specialist uses TypeScript-first schemas with defineField and defineType, and uses TypeGen for query types. Vanilla JavaScript Sanity projects suggest older work or generalist output.

Hourly billing for scoped work. A specialist who has estimated Sanity projects before can write a fixed-price proposal. Insisting on hourly for a scoped build either means they cannot estimate or that they prefer to bill for learning time.

Immediate availability with no waitlist. In-demand Sanity specialists have a short current client roster. Full immediate availability with no existing commitments is worth asking about — not a disqualifier, but worth a follow-up.

The onboarding question nobody asks

Before signing a proposal, ask: "What does your handoff look like?" A good answer includes: TypeGen types in the repo, a README covering the content model and key GROQ queries, Loom walkthroughs for editors, and documentation of any non-obvious Studio customisations. A bad answer is silence, or "I push the code and you're good to go."

The quality of the handoff is where the long-term cost of the engagement is determined. A clean handoff means the next developer spends an afternoon onboarding. A messy one means weeks of archaeology.

---

Looking to hire a Sanity CMS developer?

This is exactly the work I do — new builds, migrations, Studio customisation, and ongoing retainers for agencies. I send a fixed-price proposal with milestones after a 30-minute scope call. See engagement types and recent work →