The questions to ask before hiring a Sanity CMS developer are not the ones most founders think to ask. It is tempting to lead with portfolio links and hourly rates, but those tell you almost nothing about whether the person can actually manage a complex content structure, keep your editors happy, or hand the project off cleanly when the engagement ends.
Here are five questions that reveal what you actually need to know.
Question 1: How do you approach schema design before writing any code?
Sanity's real power is its flexible content modelling — but that flexibility cuts both ways. A developer who jumps straight into building document types without a planning phase will create a schema that mirrors whatever the design says today, rather than one that supports how your content actually grows.
What a good answer looks like: They ask about your content governance first. Who creates content, who approves it, and how many content types do you realistically publish? They mention separating content from presentation — keeping a "page" document lean and pulling in shared components through references rather than embedding everything directly. They might talk about planning for reuse across pages or channels.
Red flag: They say they will model the schema directly from the Figma file, or they cannot explain what a reference field is versus an inline object. That approach tends to produce schemas that are hard to query, full of duplication, and painful to extend later.
Question 2: Can you show me a GROQ query you wrote and explain why you structured it that way?
GROQ is Sanity's query language. It is not difficult to learn at a surface level, but writing queries that are efficient, maintainable, and safe to expose in a production application takes real experience. This question is not a quiz — it is an invitation to hear how they think.
What a good answer looks like: They can walk through a real query from a past project, explain what the projection is doing, and describe a problem it solved — such as avoiding unnecessary data being sent to the browser, or resolving a reference in a single round trip. Bonus points if they mention GROQ projections, conditional fields, or query typing with Sanity TypeGen.
Red flag: They say they just copy queries from the Sanity documentation and adjust them. That works for a simple blog, but it is a sign they have not worked through the performance and maintainability problems that come up on any non-trivial project.
Question 3: Walk me through how a content change in Sanity gets to my live site
This is the question most clients forget to ask, and it is the one that matters most for day-to-day publishing. The answer tells you whether the developer has actually shipped a production Sanity project or just built demos.
What a good answer looks like: They describe the full pipeline: an editor publishes in Sanity Studio, a webhook fires to the hosting platform (usually Vercel), and the relevant pages are revalidated so visitors see fresh content within seconds — not hours. They understand the difference between revalidating a single page and triggering a full rebuild, and they know why the former is almost always the right choice. They should also mention that webhooks need to be secured so random requests cannot trigger rebuilds.
Red flag: They say the site will rebuild automatically, but they cannot explain how or how long it takes. A full rebuild on a large site can take five to ten minutes. If your editors publish breaking news or time-sensitive product updates, that is not acceptable, and a developer who does not flag it has probably not thought through your workflow at all.
Question 4: How do you train editors to use the CMS you build?
Sanity Studio can be configured to be genuinely pleasant for non-technical editors — or it can be a wall of fields that nobody wants to use. The developer controls most of that experience, and a good one takes it seriously.
What a good answer looks like: They mention customising the Studio layout so editors see only the document types relevant to them. They talk about adding field descriptions and validation messages written in plain language, not developer shorthand. Ideally they offer a short handoff session — recorded or live — so editors are not left guessing. Some developers also provide a brief written guide tailored to your specific setup.
Red flag: They hand over login credentials and a link to the Sanity documentation. Generic documentation does not explain your custom fields, your publishing workflow, or your specific constraints. Editors who are confused will either publish incorrectly or stop using the CMS altogether, which defeats the purpose of the investment.
Question 5: What does post-launch support look like with you?
Every production CMS project needs some level of support after go-live — a schema change for a new content type, a query that needs adjusting for a new page layout, or a webhook that silently stops firing. How a developer answers this question tells you a lot about how professional they are to work with.
What a good answer looks like: They offer a clearly scoped support period — typically 30 to 90 days — with defined response times and a description of what is included versus what would be a separate engagement. They are transparent about their availability and honest about what falls outside the original scope. They also document what they built: schema decisions, environment variables, webhook configurations, and deployment notes.
Red flag: They say to just message them on Slack if anything comes up. Informal support arrangements collapse when a developer moves to a new client, goes on holiday, or simply becomes harder to reach. You want a paper trail and a process, not a favour.
Hiring the right Sanity developer is less about finding someone who knows the tool and more about finding someone who has shipped real projects, thought through the editor experience, and can explain their decisions clearly. These five questions get you there faster than any portfolio review.
