Sanity Development: A Complete Guide to Building with Sanity CMS

Sanity takes a different approach. It keeps content separate from the frontend, giving businesses more freedom over how their website is built and how content is used. You are not tied to a fixed theme or page structure. The same content can support different pages, websites, applications, and other digital experiences without maintaining a separate copy for each one.

That flexibility also changes what you can build around the content management system. Sanity Studio can be configured around your content and publishing requirements, while the frontend can use Next.js, Astro, or any other SPA framework. Sanity can exchange information with other systems, which makes it possible to connect your content with e-commerce platforms, search services, translation tools, and other software already used by the business.

This makes Sanity worth considering when an existing platform no longer provides enough flexibility, or when you are building a new website that needs room to grow. The value comes from having a content platform that fits the website you want to build instead of designing the website around the limitations of the CMS.

This guide explains what Sanity development offers, where it has an advantage over traditional content management platforms, and when it makes sense for a business. It also covers the development process, integrations, migration, costs, timelines, and what to look for when choosing a Sanity development partner.

What Is Sanity CMS?

Sanity is a headless content management system built for businesses that need more flexibility than a traditional content management system provides. In a traditional CMS such as WordPress, content management and the website's presentation are usually part of the same system. Pages are often built around themes, templates, and plugins that also shape how the content is displayed. Sanity separates content from the frontend, so the website doesn't have to follow the CMS's structure or design.

This separation gives businesses more freedom to change or redesign their website without moving all of their content to another CMS. It also eliminates the need to build each new requirement into a rigid theme or page design.

Sanity lets businesses store information as structured content they can access anywhere. Imagine you have an eCommerce store that sells hundreds of products. You can manage product names, descriptions, images, prices, and categories in a single location and apply them to product landing pages, campaign landing pages, mobile apps, or other digital experiences. When shared information changes, it only needs to be updated at its source.

This content is managed through Sanity Studio. The system can be configured to fit a business's information and publishing requirements, not the other way around.

When a content management system creates issues with inflexible page structure, duplicate content, integrations, or new digital channels, those differences become significant. Sanity provides extra flexibility for the business to adapt the website and content structure as their needs evolve.

Even after moving to Sanity, the business still needs initial website setup and a clear content structure. This investment is more worthwhile if the business needs Sanity's flexibility. If the website is simple, with just a handful of standard pages, it may not require the same customization.

How Sanity's Architecture Works

Sanity separates the place where content is managed from the website where people see it. The website uses the content your team manages in Sanity and displays it in its own design.

For instance, a business can have product names, descriptions, pictures, client stories, and company details. It stores information once and reuses it wherever you need it, rather than adding it to multiple pages.

A simple example of an author profile. If the same author has written 50 articles, their name, photo, and other details do not need to be added to every article. The business stores only one author profile and links it to the articles. If the profile changes, you only need to update the information once.

The same content is not restricted to one website. Information stored in Sanity can be utilized on any website, regional site, mobile app, or other digital platform that a business uses.

The arrangement is easy to comprehend:

Manage content in Sanity → Store it in one place → Use it on your website and other digital platforms

The site design stays clean and intact. A business can redesign its website or create a new digital experience while still leveraging the existing content it manages in Sanity.

This configuration helps if your business has many pieces of connected content that rely on the same information, or if you plan to add more websites and digital channels in the future.

What Does Sanity Development Involve?

Sanity development covers the content structure, editing workspace, frontend connection, integrations, and any content that needs to move from an existing CMS. The amount of work depends on the project. A marketing website with a few content types needs a simpler setup than an ecommerce site with thousands of products and several connected systems.

Each of these areas requires different development work, starting with how the content itself is structured.

Content Modeling and Schema Design

Content modeling is how information is structured inside of Sanity. You can create separate content types for products, articles, authors, services, locations, and other information, rather than tying it to a specific page on the website.

Consider a business that displays the same customer testimonial on five landing pages. If you create five separate copies, you have to make a change five times. Sanity can store the testimonial once, and assign it to every page that references it.

The same technique applies to product information, company information, authors, categories, and other repetitive information. One source can supply information to different parts of a website or to other connected applications.

This becomes more useful as content grows. If you have a website with hundreds of products or articles, the structure must be clear, with no need to copy and maintain information in multiple places.

Conventional CMS platforms also support custom content types and reusable fields. Sanity is built with structured content, and these relationships are constructed in the content model; not every page is a content item.

The model must accurately represent how the business uses its information. The new CMS was designed to prevent duplication and maintenance issues, but a poor structure can cause them.

Sanity Studio Customization

Content is managed in Sanity Studio, which can be configured around the information a business manages, the people using it, and its publishing process.

A business with products, articles, landing pages, and customer stories does not need to handle everything with the same editing format. Content can be separated into sections, with different editing controls and fields for each type.

For example, a location entry may require an address field and a map field. A product may require images, specifications, categories, and related content. Those requirements can be tailored into the editing screen.

The setup is also subject to permission settings. Some users may only need to update content, while others need broader access to publishing or project settings. The available roles and access controls depend on the Sanity plan.

Sanity Studio also supports custom components and plugins when standard editing options aren't enough.

This gives a business greater control over the CMS itself. The Studio environment doesn't require a traditional publishing site workflow; instead, it can be structured around the website's content and publishing requirements.

Querying Content with GROQ or GraphQL

Different pages need different parts of the content stored in Sanity. A product listing may need a name, image, and price. The product page may also need specifications, related products, categories, and supporting articles.

Sanity uses GROQ to retrieve this information. A query can select the required content, filter it, follow relationships between documents, and return the information in the structure the website needs.

This is useful when content has several relationships. For example, a product page may need information from the product itself, its category, related products, and buying guides. GROQ can retrieve these connected records as part of the requested result.

A standard REST API commonly exposes content through resource-based endpoints. Depending on the CMS and API design, connected information may require additional requests, embedded resources, or custom endpoints. WordPress, for example, supports REST API field selection, embedded resources, and custom endpoints, so this capability isn't unique to Sanity.

The difference is the way GROQ approaches the request. It lets the application describe the content and result structure it needs, rather than being limited to a predefined endpoint response. Sanity's GROQ documentation covers filtering, projections, references, and other query options.

Front-End Integration

Sanity manages content separately from the website where it appears. What users see on the website depends on the frontend, including the design, page layouts, navigation, and available features. Sanity provides the content but does not define how it should look.

A business can build that frontend with Next.js, Astro, React Router, or another suitable framework. This gives the development team the freedom to choose the technology and design based on the website's requirements, rather than working within a theme provided by the CMS.

The same content is not limited to one design or platform. Product information managed in Sanity, for example, can appear one way on a website and differently in a mobile application while coming from the same source.

The frontend also determines how editors preview their work. Sanity's Presentation Tool connects Sanity Studio to the website, so users can review content in the actual page layout before publishing.

If the website is redesigned later, the existing content can remain in Sanity. Developers can build a new frontend and continue using the same content instead of moving everything to another CMS.

Integrations

The number and type of integrations depend on the systems the business already uses. Sanity can exchange information with e-commerce platforms, search services, translation tools, asset management systems, and other applications.

An e-commerce website may use Sanity for product descriptions, buying guides, landing pages, and promotional content while Shopify continues to manage inventory, prices, and checkout. The integration determines which information stays in each system and how updates move between them.

Search has a different requirement. GROQ can retrieve and filter Sanity content, while a website that needs dedicated search features may connect a service such as Algolia.

Existing systems do not always need to be replaced. A business that already has a digital asset management system can connect it with the content workflow instead of moving its entire asset library into a new platform.

Multilingual websites may also connect translation services or plugins. Sanity offers AI Assist for supported AI-assisted content tasks in Studio.

The development work changes with each connection. Adding analytics is different from keeping product information synchronized between Sanity and an e-commerce platform. The systems, data, and update direction need to be clear before we estimate the integration.

Migrating Content from an Existing CMS

Moving to Sanity starts with the content already stored in the current CMS. The amount of migration work depends on its volume, structure, assets, and the difference between the old and new content models.

A WordPress website may have articles, authors, categories, images, landing pages, and custom fields. These records need to be mapped to the new Sanity structure before import.

Not everything has to move as-is. Duplicate content can be consolidated, outdated pages removed, and information that appears in several places can be reorganized for reuse.

URLs need to be reviewed as part of the migration. If an existing page moves to a different address, a redirect may be required so visitors and search engines still reach the correct content. Images, metadata, and relationships between content also need to be checked.

A migration is therefore more than moving records from one CMS to another. It is also an opportunity to correct content problems that have accumulated in the existing website before the new system goes live.

Sanity Website Development Process: Step-by-Step

A Sanity website project starts with understanding the content, website requirements, and systems that need to work together. These decisions shape the content structure, frontend, integrations, migration work, and testing required before launch.

The process differs slightly for a new website and an existing one. A new website can build its content structure around Sanity from the beginning. A migration also has to account for existing pages, images, URLs, content relationships, and integrations. The development process usually moves through the following stages.

1. Discovery and Content Audit

The first step is to understand what already exists and what the new website needs. This covers pages, content types, integrations, user access, and the current publishing process.

For an existing website, the audit also determines what is worth moving. A site with 500 pages may contain outdated pages, duplicate information, or content that is no longer useful. Moving everything without reviewing it would carry the same problems into the new CMS.

The review also identifies information that appears in several places, such as company details, author profiles, product specifications, or testimonials. These findings help developers plan the new content structure and estimate the migration and development work more accurately.

2. Content Modeling

The next step is to decide how information will be organized in Sanity. Articles, products, authors, categories, locations, and other content are structured according to how the business creates, connects, and reuses them.

The model should be tested against real content before development moves further. An article may need an author, category, image, and related articles, while a product may need specifications, images, categories, and supporting content. Testing real examples helps uncover missing fields or relationships early.

A well-planned model also reduces duplicate work. Information used on several pages can be stored once and connected where needed instead of being maintained as separate copies.

3. Sanity Studio Configuration and Editor Workflows

Once the content model is clear, Sanity Studio is configured around the people who will manage the website. This covers navigation, editing fields, validation, permissions, and any custom controls required for publishing.

The setup should also be tested through everyday tasks. Editors might create an article, update a landing page, find an existing product, preview a change, and publish an update. These tasks often reveal usability problems that are difficult to see from the content model alone.

The amount of customization depends on the project. A small marketing site may need a straightforward Studio setup, while a larger website may require separate sections for products, locations, articles, and landing pages.

4. Front-End Development

The frontend turns the approved designs and Sanity content into the website visitors use. Developers build the page layouts, navigation, responsive behavior, reusable sections, forms, images, and other required features.

This stage also determines how content appears across the website. A product, for example, may appear as a small card on a category page and as a detailed view on its own page, while both use the same product information stored in Sanity.

Developers also plan how pages load and receive content updates. A website that publishes frequently may need a different setup from one where content changes only occasionally. This decision affects how quickly new content appears and how efficiently pages load.

Preview functionality is also connected at this stage when required, allowing editors to review unpublished changes in the actual page layout before they go live.

5. Integrations

The website is then connected to the external systems required by the business. These may cover e-commerce, search, analytics, translation, digital asset management, or other existing tools.

An e-commerce website, for instance, may keep inventory, prices, and checkout in Shopify while Sanity manages product descriptions, buying guides, and promotional content. Developers need to establish which system owns each type of information and how the website brings that information together.

Integration effort varies. Adding analytics is relatively contained, while synchronizing information between two systems requires more planning, testing, and error handling. Each connection therefore needs to be reviewed according to what information it sends or receives.

6. Content Migration

For an existing website, content is mapped from the current CMS to the new Sanity structure. Articles, products, authors, categories, images, and other records may not fit the new model exactly, so some information may need cleaning or restructuring before import.

URLs also need attention. Existing addresses should remain the same where possible. If a URL changes, the old address needs to direct visitors and search engines to the correct new page. Images, metadata, and relationships between content should also remain intact.

Sanity provides import tools for moving structured content and assets. The amount of migration work depends on the volume and condition of the existing content and how different the new structure is from the old CMS.

7. Preview, QA, and Performance Testing

Testing covers both the public website and the publishing experience. Pages are checked across different screen sizes and browsers, along with links, forms, images, accessibility, integrations, and performance.

Content also needs to go through its normal publishing process. A change made in Sanity should appear in the correct place, previews should display the expected version, and unpublished content should remain private.

Connected systems need their own checks as well. Search, e-commerce, forms, and other integrations should continue working when data changes or an external service fails. Finding these issues before launch reduces the risk of fixing them on the live website.

8. Launch, Editor Training, and Iteration

After testing is complete, the website moves to production. The live version is checked again to confirm that pages, content, forms, and integrations work as expected.

Editors also need to understand the new setup. Training should focus on the tasks they perform regularly, such as creating content, updating pages, finding existing records, using previews, and publishing changes.

The work does not always stop at launch. Larger Sanity websites often change as the business adds new content types, markets, integrations, or website features. Feedback from editors and real website use helps identify what should be adjusted after launch.

For a broader explanation of planning, development, testing, and deployment, read our Web Application Development Process guide.

When Sanity Is the Right Choice, and When It Isn't

Sanity makes sense when a growing website becomes harder to manage. Products, pages, markets, and integrations may increase, while the existing CMS starts relying on more plugins, duplicate content, or workarounds.

An e-commerce business, for instance, may use the same product information across product pages, buying guides, campaigns, and a mobile app. Sanity lets the business manage that information in one place and connect products with categories, FAQs, guides, and related content.

It also works well when the website needs to connect with existing commerce, search, translation, or other business systems. Sanity Studio can be set up around different content types and publishing needs, giving editors a workspace that matches the way they manage content.

Sanity is not necessary for every website. A small business site with a few standard pages may be easier and cheaper to manage with WordPress or a website builder. Businesses that mainly want a ready-made theme and a quick launch may also find those options more practical.

Sanity also needs development support when the website, content structure, or integrations need major changes.

Sanity is a better fit when content is growing, being reused in several places, or becoming difficult to manage in the current CMS. If the existing setup already works well for simple content needs, there may be little reason to replace it.

Sanity Development Cost and Timeline

Sanity project costs depend on the website, content structure, integrations, migration work, and level of customization. The budget usually has two parts: the Sanity subscription and the development work needed to build and maintain the website.

Sanity Platform Pricing

Sanity offers three plans: Free, Growth, and Enterprise. The price depends on the number of paid users, required features, and usage limits.

The official Sanity pricing page lists the following prices and allowances.

A Growth project with five paid users starts at $75 per month, before additional usage or add-ons. Traffic, storage, content volume, and other platform usage may increase the monthly cost.

The subscription does not cover website design and development, migration, integrations, or ongoing technical work. These costs depend on the project scope.

Typical Timelines

A CMS-backed marketing website usually takes around 6–10 weeks when the design, content, and main functionality are already defined, based on our Next.js development benchmark. This is a planning benchmark, not a fixed Sanity timeline.

Migration and integrations often add more time. Moving 500 articles with the same structure may be easier than moving 100 pages built with different layouts, plugins, and custom fields. Duplicate content, missing assets, or inconsistent data also require additional work.

The frontend matters as well. Approved designs and defined page types make development easier to estimate, while changing requirements extend the schedule.

A reliable estimate therefore comes after reviewing the existing website, content, integrations, and frontend requirements.

Sanity Development Services: In-House Developers vs a Sanity Agency

If your developers are already familiar with Sanity, your existing systems, and will work with your website after launch, building in-house may make sense. An agency can be more convenient if you are developing a new site, moving to Sanity, or integrating with a different system and don't want to hire full-time developers.

Continuous work is also a factor. Frequent development might suit an in-house team, while project development might suit an agency. In both cases, the required skills must be in place.

Skills a Sanity Developer Needs

A Sanity developer needs to understand the CMS and the website built around it. This begins with structuring content, articles, categories, etc. so that editors can easily update and reuse information without duplication.

Frontend experience is also a factor. The developer must know Next.js and Sanity if the website is built on Next.js. Integration experience is also required for commerce, search, translation, or other system integrations.

For larger projects, you may need a custom editing workspace, custom fields, or content sections with permissions. Sanity Studio customization supports this type of setup.

When evaluating developers, look for their experience in the relevant field. If someone has experience with a migration, integration or content structure similar to what you are going through, they might be a better fit than if they have a longer list of unrelated Sanity projects.

In-House vs Agency Trade-Offs

The cost is one difference between hiring developers and working with an agency. An in-house team comes with salaries, recruitment, benefits, tools, and management costs. An agency usually charges for the project or for an agreed amount of ongoing work.

An internal team makes more financial sense when there is enough development work throughout the year. An agency may suit a migration, website rebuild, or another project that needs specialist skills for a limited period.

If an agency builds the website and your team takes over afterward, plan the handover before the project ends. Your team should receive the code, documentation, deployment details, and information needed to maintain the Sanity setup.

The best option depends on your existing skills, the amount of ongoing work, and how much Sanity experience the project requires.

How CodingCrafts Approaches Sanity Development

At CodingCrafts, we start by understanding the website, its content, and how the team needs to manage it. Before determining the level of customization required for the Sanity setup, we review the existing content, frontend requirements, integrations, migration work, and publishing process.

We followed this approach for a real-time AI data platform that needed a new marketing website built with Sanity and Next.js. The marketing team wanted to have more control over landing pages without relying on developers for each change.

We built a custom drag-and-drop content builder in Sanity, so the team could create and update landing pages on its own. In internal testing, this saved 40–50% of the time spent publishing and testing compared with the previous developer-driven process.

This setup is not required for all projects. For a smaller site, you might only need a simple content organization, a simple Studio configuration, and a custom frontend. A larger project could require migrating years' worth of content, connecting multiple systems, or more complex publishing needs.

We review these requirements before development. This will guide us in determining what we should create, what existing content should be modified, and when Sanity's out-of-the-box functionality is sufficient. It also eliminates unnecessary development.

If you are planning a new Sanity website or moving from another CMS, contact CodingCrafts to discuss your project.