What is Sanity, and what does a Sanity CMS developer actually build?
Sanity is a headless content platform made of two parts: a hosted database called the Content Lake that stores your content as structured JSON documents, and Sanity Studio, an open-source React application where editors write and manage that content. A Sanity CMS developer builds the bridge between them and your website: the schemas, the Studio, the queries and the front end.
Unlike WordPress, Sanity ships with almost no opinion about how content looks. You define every document type in code: an article has a title, slug, author reference, hero image and body; a product story has a product reference, a lookbook gallery and a call to action. The Studio then generates an editing interface from those definitions, which the developer tailors further.
That makes Sanity strongest for structured content: pieces that get reused across pages, channels and languages. A recipe publisher can show the same ingredients on a web page, in a mobile app and in a printable card. A brand can reuse one testimonial on the homepage, a product page and a campaign landing page, edited once.
Content Lake
Sanity's hosted store for your documents, queried over an API and served through a CDN.
Sanity Studio
The editing app, configured in JavaScript or TypeScript, deployable to Sanity's hosting or your own.
GROQ
Graph-Relational Object Queries, Sanity's query language for fetching exactly the fields a page needs.
When is Sanity the right CMS, and when should you skip it?
Choose Sanity when several people edit structured content together, when the same content appears in more than one place, and when you would rather not maintain a CMS server. Skip it when one person updates a small site a few times a year, or when policy requires content on servers you control.
Sanity's real-time collaboration is its signature. Two editors can work on the same document and see each other's cursors, with version history underneath. For newsrooms, marketing teams with weekly campaigns and brands running many product stories, that removes a lot of “who overwrote my change” friction.
The cost of that convenience is dependence on a hosted service with plan limits. For a small business with one editor, a static site or simple WordPress build is cheaper and easier. For a team that wants content inside its own database, Strapi is the closer fit. A Sanity CMS developer worth hiring will tell you this before quoting.
- Good fit: content teams of three or more editing weekly
- Good fit: one content source feeding website, app and campaigns
- Good fit: developers who want schemas in code and version control
- Poor fit: a five-page site updated twice a year
- Poor fit: strict rules that content must stay on your own servers
Sanity schema design: how a Sanity CMS developer models your content
Schema design is deciding which document types exist, which fields each has, which things are references to other documents and which are embedded objects. Get it right and editors never copy-paste the same thing twice; get it wrong and every redesign becomes a content migration.
We start by listing the “nouns” of your business and how they relate: authors write articles, articles belong to topics, products have variants and stories, stores have locations and opening hours. Anything that appears in more than one place becomes its own document and is referenced. Anything that only makes sense inside its parent, such as a call-to-action block or an image with caption, becomes an object.
Rich text in Sanity is stored as Portable Text, a structured format rather than raw HTML. That matters: the same body can render as HTML on the web, native text in an app and plain text in an email, and you can embed custom blocks such as product cards, callouts or video inside it. A Sanity CMS developer defines which blocks are allowed so articles stay consistent.
Validation belongs in the schema, not in the editor's memory. Required fields, character limits on SEO titles, image alt text requirements and slug uniqueness are all rules the Studio can enforce before publish.
Reference when
The item is reused elsewhere or edited by a different person: authors, products, categories, locations.
Embed when
The item belongs only to its parent: a hero block, an FAQ pair, a gallery caption.
Validate when
A missing or wrong value would break a page or hurt SEO: slugs, alt text, meta titles.
Customising Sanity Studio so editors stop making mistakes
Sanity Studio is a React app configured in code, so almost every part of it can be shaped around your team. The goal of Studio customisation is simple: editors find what they need in two clicks and cannot publish something broken.
The structure builder controls the left-hand navigation. Instead of one long list of every document type, a Sanity CMS developer can group content by team or channel: “Campaigns this month”, “Product stories by collection”, “Articles waiting for review”. Singletons such as site settings and the homepage appear as single entries, not lists where someone might create a second homepage by accident.
Custom input components replace generic fields where they cause errors: a colour picker restricted to brand colours, a product selector that searches your store, a map pin for store locations, a character counter on meta descriptions. Document actions can add steps such as “send for legal review” before publish. Document views can show a live preview pane or an SEO checklist next to the form.
We keep customisations small and documented. Every custom component is another thing to update when Sanity releases a new Studio version, so we build them where they save real time, not for decoration.
- Structure builder: navigation grouped by team, channel or workflow
- Singletons for settings and one-off pages
- Custom inputs for brand colours, product pickers, maps
- Validation messages written in plain language
- Preview and SEO panes beside the editing form
How do GROQ queries work, and why do they matter for speed?
GROQ, short for Graph-Relational Object Queries, is Sanity's query language. A query filters documents, follows references and returns only the fields you ask for, in the shape your page expects. A typical query reads like: fetch every article where the type is article and the topic matches, and return the title, slug, author's name and hero image.
The power of GROQ is projection: you describe the exact JSON you want back, including fields from referenced documents, in one request. A product page can fetch the product, its variants, related stories and the author of each story in a single query instead of four round trips.
That power cuts both ways. A careless query that fetches whole documents, or follows every reference, returns far more data than the page uses and counts against your plan's API usage. A Sanity CMS developer should write narrow projections, fetch through Sanity's CDN-backed API for published content, and cache results on the front end so repeated visits do not generate new requests.
We keep queries in one place in the codebase with typed results, so when a schema changes the front end fails loudly at build time rather than quietly showing blank sections to visitors.
Live preview and visual editing with Next.js: how it is set up
Live preview lets an editor see an unpublished draft rendered on the real website before pressing publish. In Sanity this runs through the Presentation tool inside the Studio, which loads your Next.js site in a preview pane and shows draft content as the editor types.
Under the hood, Sanity's documentation describes four pieces. Next.js Draft Mode provides a secure preview route so drafts are visible only to authorised editors. The Sanity client is configured with perspectives and a token to read drafts. Content Source Maps link each piece of text on the page back to its field, which powers click-to-edit overlays. The Live Content API pushes updates so the preview refreshes without a reload.
For editors, the result is that they click a headline on the preview, the Studio jumps to that field, and changes appear on the page immediately. For a Sanity CMS developer, the work is in wiring it correctly for both the App Router and any older Pages Router sections, and in making sure preview never leaks drafts to the public site or search engines.
Preview is worth the effort for teams publishing often. For a site edited twice a month, a simpler “open draft URL” button may be enough, and we will say so in the quote.
Draft Mode
A protected Next.js route that switches the site into draft-reading mode for logged-in editors only.
Click-to-edit
Overlays on the preview that jump to the exact Studio field behind any piece of text.
Live updates
The preview refreshes as the editor types, without reloading the page.
The Sanity image pipeline: hotspots, crops and modern formats
Sanity stores uploaded images once and transforms them on request through its image CDN at cdn.sanity.io. You ask for a size, crop and format in the URL, and the CDN returns a resized, compressed version. That means editors upload one high-quality original and the site gets the right version for each screen.
According to Sanity's image URL documentation, the main parameters are width and height, fit (such as crop, clip or max), crop strategy including focal-point cropping, quality from 0 to 100, and auto=format, which returns the most efficient format the browser supports, including WebP and AVIF. Editors can set a hotspot and crop in the Studio so a portrait is never cut off at the forehead when the layout needs a wide banner.
A Sanity CMS developer should generate responsive image sets from these URLs, set explicit width and height to avoid layout shift, lazy-load images below the fold and require alt text in the schema. One small but real detail from the docs: for social sharing images, set an explicit JPEG format, because crawlers may receive a different format than browsers when auto=format is used.
- One original upload, many sizes served from the CDN
- Hotspot and crop set by editors in the Studio
- auto=format for WebP or AVIF where supported
- Explicit JPEG for Open Graph and social previews
- Alt text made a required field
Sanity pricing tiers vs a self-hosted CMS: which costs less over time?
For many small and mid-sized sites, Sanity's Free plan covers everything, so the running cost is close to zero beyond the front-end host. Costs rise with more editors, private datasets and heavy API usage, where a self-hosted CMS with a fixed server bill can work out cheaper.
Sanity's pricing page lists three tiers. Free includes 20 seats, two public datasets, 10,000 documents, one million CDN API requests and 250,000 API requests a month, and 100 GB each of bandwidth and asset storage. Growth is billed per seat, allows up to 50 seats, adds private datasets and raises the document limit to 25,000. Enterprise has custom seats, roles and limits. Viewer-role users are free.
A self-hosted CMS such as Strapi has no seat fees; you pay for a server, a database and someone to maintain both. The break-even depends on team size and traffic. A three-editor marketing site on the Free tier costs less on Sanity. A twenty-editor team that needs private data and custom roles may cost less self-hosted, once you include the upkeep we or your team would do.
We check your expected editors, document count and traffic against these limits before recommending either route. Plan limits change, so we confirm against Sanity's live pricing page at quote time.
How to hire a Sanity CMS developer: what to ask and what to look for
Hire a Sanity CMS developer who talks about your editors before your front end. Ask them to sketch your schema on a call, explain which items would be references, and show you a Studio they customised. The Studio tells you whether your editors will be happy in six months.
Useful questions: how would you structure navigation for our team; how will preview work and who can see drafts; how will you keep GROQ queries within our plan's usage; what happens to our content if we leave Sanity later; which Sanity plan do you expect we need. The last two show honesty. Content in Sanity can be exported as JSON, and a good developer will explain how.
Red flags include a developer who wants the Sanity project created under their own account, one who cannot explain Portable Text, and one who promises preview “in an afternoon” for a complex site. Preview is very doable, but it needs care to keep drafts private.
Ask to see
A Studio they built, logged in as an editor, plus the GROQ queries behind one page.
Ask about
Plan sizing, preview security, and how schema changes are deployed.
Insist on
The Sanity project, Studio code and front-end repository in your organisation's name.
Sanity CMS developer cost in India: what shapes your quote
Sanity CMS developer cost in India depends on the number of document types, how much Studio customisation your editors need, whether live preview is included, how many front-end templates the site has, and whether content must be migrated in. The Sanity subscription is billed separately by Sanity.
With us, a Sanity-powered website with a Next.js front end starts at ₹20,000. That suits content-rich marketing sites, blogs, documentation and multi-location service sites. When Sanity manages editorial content for an online store, the store line starts at ₹50,000. Apps, customer portals or multi-brand content hubs start at ₹60,000. International clients see the same scope in USD, such as US$300 for a website.
The line items that move a quote most are live preview with visual editing, custom Studio input components, and content migration with rich-text conversion. We list each separately so you can drop what you do not need. Other freelancers and agencies quote across a wide range, largely because some include preview and migration while others leave them for later.
Migrating from WordPress or another CMS into Sanity
Moving content into Sanity is mainly a transformation job: old HTML posts become Portable Text, old categories become referenced documents, and old image URLs become Sanity assets with hotspots. Done carefully, editors get cleaner content than they had before.
Our steps are: export content from the old system, map every old field to a new schema field, write a migration script that converts HTML to Portable Text and uploads images, run it against a development dataset, let editors review a sample, fix edge cases (embedded videos, tables, shortcodes), then import to production. Old URLs are mapped to new ones and served as 301 redirects from the Next.js site, so search engines keep the history.
Shortcodes and page-builder markup from WordPress are the usual headache. We list them early, decide which become custom Portable Text blocks and which get flattened, and show you examples before the full import. See our website migration page for the redirect side, and traffic drops after migration for what to watch afterwards.
SEO and AI-search visibility on a Sanity site
A Sanity site ranks as well as its front end renders. We build Next.js pages that are rendered to HTML on the server or at build time, with titles, descriptions, canonical URLs and structured data generated from Sanity fields, so search engines and AI crawlers see complete content without running JavaScript.
Every page-like document type gets an SEO object with meta title and description (with length validation), social image, canonical override and a no-index switch. Structured data such as Article, Product, FAQ or LocalBusiness is generated from the same fields editors already fill in. The sitemap is built from published documents and revalidated when editors publish.
For AI answers, the same structured content helps: short, self-contained answer paragraphs, question-style headings and clear definitions are easy for AI search tools to quote. Core Web Vitals are checked in Google Search Console after launch, and the image pipeline handles most of the heavy lifting on page weight. Nobody can promise rankings; what we can promise is clean foundations. Our freelance SEO expert page covers ongoing work.
Sanity CMS developer for brands and publishers across India
We build Sanity projects remotely for teams anywhere in India, working over WhatsApp, video calls and GitHub in English or Hindi. The businesses that pick Sanity tend to have content teams rather than a single owner updating the site.
Publishers and media startups in Delhi and Kolkata use it for newsrooms where several editors publish daily. D2C and fashion brands in Mumbai and Jaipur use it for lookbooks and product stories alongside their store. SaaS teams in Chennai and Bengaluru use it for documentation and marketing sites that developers and marketers both touch.
Tourism and hospitality businesses in Kochi and Mysore reuse destination and package content across web pages and partner feeds. Education groups in Chandigarh manage campus, course and faculty content for several institutions from one Studio. Each city page linked here describes what local businesses typically ask us to build.
Ownership, handover and care after your Sanity site launches
You should own the Sanity project (under your organisation in Sanity's dashboard), the Studio code, the Next.js repository, the hosting account for the front end and the domain. We join as members with the access we need and step back at handover.
At handover you receive the repositories, a list of document types with plain-language descriptions for editors, notes on how preview and webhooks are wired, and guidance on your current plan's limits and how to watch usage in Sanity's dashboard. Studio and front-end dependencies are pinned and documented, so the next upgrade is a planned task.
For two months after launch, maintenance is free: Studio and package updates, small fixes, new fields when editors ask for them, and help if usage approaches your plan's limits. After that, care starts at ₹8,000/mo a month if you want it. Anything else is agreed in your written quote. If you ever leave Sanity, your content can be exported as JSON, and we can help you plan that move too.
Worked example: a hypothetical D2C brand running content on Sanity
Suppose a handloom saree brand in Jaipur (an illustrative scenario, not a real client) sells through an online store and wants richer stories: weaver profiles, collection lookbooks, care guides and campaign pages, edited by a four-person marketing team every week.
A Sanity CMS developer would define Weaver, Collection, Lookbook, Story, Care Guide and Campaign documents, with Collection referencing store products by ID. The Studio would group content by “This week's campaign”, “Collections” and “Evergreen guides”, with a product picker input that searches the store. Portable Text in stories would allow product cards and pull quotes as custom blocks.
The Next.js front end would fetch through narrow GROQ queries, use the image pipeline with hotspots so model shots crop well on phones, and run live preview through the Presentation tool so the team sees campaign pages before launch. Four editors fit inside the Free plan's seat allowance, so Sanity's cost would likely stay at zero at first.
In quote terms this would sit on the store line (from ₹50,000) if we also build the commerce side, or on the website line (from ₹20,000) if the store already exists and only the content layer is new. Timeline: roughly four to six weeks, depending on how quickly photos and weaver stories arrive.
Sanity CMS developer checklist before launch
Go through these points with your developer on a screen-share before launch day. Each one prevents a common problem we see on Sanity sites built in a hurry.
- Sanity project sits under your organisation, not the developer's
- Every document type has editor-friendly titles and help text
- Validation blocks publishing without slugs, alt text or SEO titles
- Singletons cannot be duplicated
- Preview shows drafts only to editors, never to the public or crawlers
- GROQ queries use narrow projections and the CDN for published data
- Publish webhooks revalidate the right pages
- Social images are served as JPEG; page images use auto format
- Usage is within your plan, with a note on when to upgrade
- Repositories, domain and hosting are in your name
Already on Sanity and unhappy with the Studio or speed? Share read access to your repository and a Studio viewer account, and we will list what we would change first. Our React developer page covers wider front-end work.