Sanity CMS development for structured, headless content - modelled once, served to every surface.
Intention InfoService models your content as structured data on Sanity - typed schemas, a custom Studio and GROQ queries - and builds the fast front end that reads it in Next.js or Astro, by a small senior team at transparent published fixed prices. You own your content, your schema and your Studio; the Content Lake is Sanity's hosted service you pay for directly. For startups, SMBs and enterprises worldwide.
Fixed price, content you own, no in-house lock-in.
- You own your content and schema
- Published fixed pricing
- Content as data, not pages
Sanity in 2026Headless
- Content model
- Typed schemas, in code
- Query
- GROQ, joins in one request
- Studio
- Open-source React, yours
- Delivery
- Real-time or cached, per surface
Content stored as structured JSON - queried and reused across web, app and whatever surface comes next.
Structured content, a custom Studio, and the front end that reads it
Sanity is the content backend - we model your content, build the Studio your editors use, and write the data layer, then pair it with a front end that renders fast. A typical Sanity engagement is one of these:
Content modelling & schema design
The foundation: your content types modelled as typed schemas in code - documents, reusable objects, references and Portable Text - shaped around how your team actually works, reviewed in your repo like any other code.
A custom Sanity Studio
Sanity Studio stood up in your repository and built as a product, not a rented admin: custom input components, a structure editors can navigate, roles and real-time collaboration wired to your real editorial workflow.
The GROQ data layer
The queries the front end needs, written in GROQ - filtered, dereferenced and projected to exactly the fields each view renders - with TypeScript types generated from them, so the data contract is checked end to end.
The front end that reads it
Sanity is the backend; the site is built on a front end that reads it over GROQ or the API - Next.js for app-grade and SEO-critical sites, Astro for content sites - with visual, in-context preview so editors see changes live.
Editorial workflows & multi-locale
Coordinated publishing that groups related changes to go live together, scheduling for individual documents, a shared media library, and field- or document-level internationalization for multi-language content.
Migrations onto Sanity
Moving off WordPress or a legacy CMS onto structured content: we model the target schema first, script the extract and transform, load into a non-production dataset to verify, and map URLs with redirects so the SEO survives the cutover.
Sanity is the backend - here is what reads it, and when it is the wrong CMS
Sanity does not render your website; it stores and serves your content. The site is a front end, and sometimes Sanity is not the right CMS at all - here is where each of those goes:
The front end for an app or an SEO-critical site - Next.js, the React front end that reads Sanity is where that build happens - server rendering, on-demand revalidation from Sanity, and the interactivity of a real application. Sanity models and stores the content; the site itself is the front end.
The front end for a fast content or marketing site - Astro, a fast content-site front end over Sanity is the leaner pairing when the site is mostly static content - Astro reads Sanity as its source and ships almost no JavaScript. We build both front ends and pick the fit.
A team that just wants to edit whole pages in a familiar admin - WordPress, the traditional page-based CMS is often the right, cheaper call - a themed admin your team already knows, with plugins. Sanity earns its keep when content is structured and reused across surfaces, not when a single team edits pages in place.
Your content isn't a stack of pages. It's structured data you can query.
A traditional CMS stores your content as pages - a title, a blob of HTML, done - and the moment you need that same content somewhere else, you copy it, and the copies drift. Sanity treats content as data instead. You model it once as typed schemas, store it as structured JSON in the Content Lake, and query it with GROQ - so one article, product or author is authored a single time and served to your website, your app, an email, and whatever surface comes next, without being retyped into each one. The abstract version is "content as data, not pages." The concrete version is: write it once, publish it everywhere, and never keep three drifting copies of the same paragraph again.
What structured content gives you
Sanity is built on one idea - content is data - and everything else follows from it. Here is what that buys you, and, honestly, when a simpler tool is the better call.
Write once, publish everywhere
Because content is structured data rather than a page, the same article, product or author is authored once and rendered on a website, a mobile app, an email or a screen that does not exist yet - no retyping the same copy into three systems that then drift apart.
Content you can actually query
GROQ filters, follows references and reshapes your content in a single request, so a view gets exactly the data it renders and nothing more. Your content is a queryable store, not a pile of HTML you scrape.
A content graph, not duplicated fields
A reference points one document at another - a post at its author, a product at its category - so you change a thing once and everywhere that references it updates. You compose relationships instead of copy-pasting the same data into every page.
Rich text that stays structured
Portable Text keeps formatted content as typed data, not a blob of markup, so the front end decides how each heading, link and embedded block renders - and the same rich text can be presented differently on different surfaces.
A Studio your team can build on
The editing environment is an open-source React application you configure and extend in code - custom fields, previews and workflows shaped to your team - not a rented admin panel you have to work around.
Structured, so it moves
Content modelled as JSON is exportable and portable by design - it is not trapped inside a page template or a theme. Combined with an open-source Studio and schema in your repo, the parts that encode your work stay in your hands.
Is Sanity too developer-heavy for my editors? Only at the start - and that is the point.
Honest yes-and-no. Standing Sanity up is a developer job - someone has to model your content as schemas in code before anyone can edit a word - and that upfront modelling is exactly what you are paying for. Once the schemas exist, editors never touch code: day-to-day editing is a real-time, collaborative environment with structured fields and rich text. But if what your team wants is to log into a familiar admin and edit whole pages with no developer in the loop, that is a WordPress job, and we will route you straight there rather than sell you a mismatch. Not sure which side you are on? We will make that call with you before we quote.
From schema to query to a live front end
There is no Sanity running this Next.js site to point at, so the proof is the discipline. Everything here is a decision you can inspect on a build we deliver - a schema in the repo, a GROQ query, a Studio config - which is the point: you should never have to take our word for what good structured content looks like.
Typed schemas, in code
Content types are modelled as typed schemas in TypeScript - documents and reusable objects with named, typed fields - so the content model is a contract that lives in your repository and is reviewable in a pull request. What you check: the schema is code you own, not a config buried in a vendor's admin.
References and the content graph
A reference field points one document at another with real referential integrity, so queries walk the links and a delete is blocked while something still points at it. You compose a graph, not duplicated fields - change an author's bio once and every post reflects it.
Portable Text and validation
Rich text is Portable Text - open, JSON-based structured content, not an HTML string - so the front end decides how each mark, heading and embedded block renders. Validation rules on the schema (required, length, custom) enforce the model at author time, not at build time.
GROQ: joins in one request
GROQ filters, dereferences relationships inline, projects exactly the fields a view needs, orders and paginates - all in a single request, no waterfall of follow-up calls. Paired with generated TypeScript types, the shape of the data is type-checked against the schema in your editor.
The Content Lake and datasets
Content lives in the Content Lake as structured JSON, in one or more datasets - a production set plus staging or preview sets - so a migration or schema change is rehearsed against a copy first. Reads come cached through the API CDN for fast public delivery, or uncached for fresh, consistent reads. (The Content Lake is Sanity's hosted service - see the ownership section.)
Real-time, and GROQ or GraphQL
Sanity is real-time at its core: the Live Content API serves low-staleness reads alongside the cached API CDN, so you pick freshness per surface, and Studio listens to the same stream. GROQ is the native language; a typed GraphQL API is available too, with an honest caveat we would tell you up front - GraphQL here does not do subscriptions or mutations, so anything real-time or write-heavy goes through GROQ.
Studio as a React product
Sanity Studio is an open-source React application you configure in code, deploy yourself, and keep in your repository - so we treat it as a product: custom input components, structure editors can navigate, document actions and in-context previews. Building React interfaces on an API is the exact work we do every day.
Editorial operations
Studio ships real-time collaborative editing with presence, plus roles and permissions for who can edit, review and publish. For launches that span many documents, Sanity supports grouping related changes to publish together and scheduling individual documents, and assets live in a shared, searchable media library. We wire these to your real editorial workflow.
AI, as Sanity's own capability
Sanity ships AI as content operations - inline, field-level assistance in Studio, AI-assisted authoring, and schema-aware editorial automation that can create and update documents that fit your model within an editor's permissions. We enable and configure what you want; we do not rebrand Sanity's AI as a proprietary offering of ours.
The front-end pairing
Sanity is the content backend, not the website. The site is built and deployed on a front end that reads Sanity over GROQ - Next.js for app-grade and SEO-critical sites, Astro for content sites - with visual, in-context editing and live preview. The front-end build is real work we route to those pages; Sanity owns the CMS side.
Webhooks, revalidation and images
Publishing fires GROQ-powered webhooks - you describe which changes matter and Sanity calls your endpoint only for those - which on a Next.js front end triggers on-demand revalidation, so an edit refreshes exactly the affected routes within seconds. Images run through Sanity's transform pipeline and CDN: store the original once, request sized, cropped, format-shifted variants at the URL.
Internationalization and migration
Multi-locale content is handled with field-level or document-level internationalization, chosen per project. Moving onto Sanity from WordPress or a legacy CMS is a real migration: model the target schema first, script the extract and transform, and load into a non-production dataset to verify content and relationships before cutover - a defined engineering task, not a copy-paste marathon.
How we take on a Sanity build: model the content as typed schemas first, because every later decision inherits from it; stand up the Studio as a product wired to how your team edits; write the data layer in GROQ with generated types; then build the front end that reads it in Next.js or Astro, with on-demand revalidation so a publish refreshes only the affected routes. And when the job is really a team editing pages in a familiar admin, we will tell you that is WordPress, not Sanity.
Our blog, guides and glossary run on Sanity.
Our site is a static Next.js and React build, and everything under Resources - this blog, the guides and the glossary - is served from Sanity: modelled in a Sanity Studio, stored in the Content Lake, and queried with GROQ on a Next.js front end. This is the one spoke where we dogfood the exact tool we're selling you - we didn't just recommend Sanity, we put our own content on it, and you're reading the result. That is first-hand experience stated as experience: the capability depth on this page is what we actually run, not a borrowed case study. Sanity is API-first and pairs with Next.js and React, and Sanity Studio is itself a React application, which is our home ground. What we still won't do is show you a Core Web Vitals or Lighthouse score for your build before we've measured it on your real content and pages after launch.
The depth on this page is the demo
The capability detail above is written by people who know current Sanity practice cold - schemas defined in TypeScript, GROQ with generated types, Portable Text, the Content Lake and datasets, the Live Content API alongside the cached API CDN, a Studio built as a React product, and on-demand revalidation on a Next.js front end. Dated or hand-wavy Sanity vocabulary is how a buyer spots an amateur; ours is current, and that competence, stated as capability and never as a result we invented, is the proof that actually travels. Everything we claimed is a decision you can inspect on a build we ship, not a number you have to believe.
You own your content, schema, Studio and queries
Here is the honest line on lock-in, drawn the same way we drew it for Shopify. Your content is structured JSON you can export at any time through Sanity's CLI; your schema and your Sanity Studio are open-source (MIT) and live in your own repository; and your GROQ queries are yours - so the parts that encode your work are portable and in your hands. What you do not own is the Content Lake: that is Sanity's hosted service, a SaaS you pay Sanity for directly. Migrating off any hosted platform is real work, and we won't pretend it isn't - but your content is exportable, structured data rather than a database held hostage, and you can move to any other Sanity developer without asking us.
No in-house layer, by construction
Standard, open Sanity any competent team can pick up: a conventional Studio, schemas defined in TypeScript, GROQ and Portable Text, on the mainstream npm and Node toolchain. We never wrap your content model in a bespoke framework only we understand, so a bigger team or the next agency can take it over without us in the room.
We adopt or migrate after an audit
Already have a Sanity project, or a CMS you want moved onto structured content? We start with a paid audit, model your content and map your URLs with redirects so the SEO survives, and pick the codebase up where it is - no rip-and-replace as a reflex.
Senior people, direct, since 2016
You talk to the engineers who model your schemas and write your GROQ - no account-manager layer, no offshore hand-off, no juniors learning Sanity on your budget. Intention InfoService is a real, incorporated company, small and senior on purpose, so the content model stays consistent from build to deploy.
Honest about partners, certs and attestations
The Sanity agency partner program is real - Sanity vets agencies with a track record of shipping Sanity work into a public directory - and we are not a Sanity agency partner and are not in that directory; it is earned on a body of Sanity work we do not yet have, and we won't imply otherwise. There is no company-level Sanity certification: the Sanity Developer Certification is an individual credential a developer earns, and the exam is currently offered only to developers at Sanity's own partner agencies and enterprise customers - so it is not something we could even sit today, let alone hold as a company badge. We hold no SOC 2 report and no ISO 27001 certification, and there is no HIPAA certification for anyone to hold. If your project legally needs a vendor who carries a formal attestation, we will say so plainly.
No markup, and no score we invented
You pay Sanity directly for the Content Lake at their own price - no referral markup or affiliate kickback that could quietly shape what we recommend - and we will not show you a Core Web Vitals or Lighthouse score for your build before we've measured it on your real content and pages after launch. Performance is engineered, then measured on the real thing, never a number we typed.
The real work behind this honesty
We have real Sanity work, not just an endorsement. Our own resource library - this blog, the guides and the glossary - is modelled and served from Sanity. And on the professional training platform rebuild you can see on our work page, we moved the client's blog and editorial content onto Sanity so their marketing team publishes on its own, with no developer in the loop. We won't overstate the scope: that project's course catalog and city pages were not in Sanity - Sanity carried the editorial layer, which is exactly the job it does best. Between that build and this site, the Sanity-specific proof is not a borrowed case study but content we actually model, query and ship - plus the standard, open Sanity code you would own outright. You can see the training-platform build on our work page.
How we build on Sanity - model the content first, and everything follows
The content model is the foundation the Studio, the queries and the front end all sit on, so we design it before we build anything - and most Sanity builds go from kickoff to live in weeks, not months.
Model the content first
firstBefore any UI, we design the schema in TypeScript - documents, reusable objects, references, Portable Text and validation - agreed in your repo as code. Getting the content shape right is the whole game, because everything downstream inherits from it.
Build the Studio as a product
before contentWe stand up Sanity Studio in your repository, configure the structure so editors navigate the way they work, add custom input components and previews where a plain field is not enough, and set roles, collaboration and the editorial workflow to your real team.
Write the data layer in GROQ
in sprintsWe author the queries the front end needs - filtered, dereferenced and projected to exactly the fields each view renders - and generate TypeScript types from them, so the data contract is checked end to end. We choose cached or real-time reads per surface.
Pair the front end, make it reactive
the buildWe build the site on Next.js (app-grade, SEO-critical) or Astro (content-and-marketing), reading Sanity over GROQ, and wire GROQ-powered webhooks to on-demand revalidation so a publish refreshes exactly the affected routes - plus the image pipeline and, if needed, internationalization.
Migrate, verify, hand over
on deliveryFor a move onto Sanity we script the extract and transform, load into a non-production dataset first, verify content and relationships, then cut over with URLs mapped. We hand you a Studio and schema you own in your repo, documented, with the queries and revalidation wired.
Sanity or a traditional CMS? Match the CMS to how your team works
We're stack-agnostic, so this is fair, not a pitch. The real choice is not brand versus brand - it is whether your content is structured and reused, or a single site your team edits in place.
| Structured & headless (Sanity) | Traditional & page-based | Hosted site builder | |
|---|---|---|---|
| Content shape | Typed, reusable data you query | Pages edited in a themed admin | Blocks in a drag-and-drop UI |
| Who edits day to day | Editors, once developers model the schema | Editors, in a familiar admin | Anyone, visually, no developer |
| Reuse across surfaces | One source to web, app and beyond | Mostly a single website | The one site on the builder |
| Front-end freedom | Any front end you build (Next.js, Astro) | The theme, or headless with work | The builder's own templates |
| Hosting & ownership | Studio and schema yours; Content Lake hosted | Self-host and own the whole site | Hosted - you rent the platform |
| Best when | Content is structured and reused, with custom workflows | One team edits one site, simply | A quick site with no developers |
Sanity earns its keep when content is genuinely structured and reused across surfaces, when you need custom editorial workflows, or when the CMS has to outlive the original build. When a single team just edits pages in a familiar admin, a traditional CMS like WordPress is often the simpler, cheaper call - and we will say so. Sanity sits in the same structured, headless family as Contentful and Strapi; the right one depends on your editorial model and budget, and we recommend the fit, not a badge we hold.
What a Sanity build costs
No quote wall. A Sanity build - the content model, the Studio, the data layer and a Next.js or Astro front end - is priced by our published web tiers, the same numbers as everywhere else. You always see the price before you commit.
Starter
1 week
A single-page site or landing page, live fast
Launch Sprint
2-3 weeks
Startups needing a fast, credible site
Growth Site
3-5 weeks
SMBs that want a lead engine
Commerce Sprint
4-6 weeks
DTC / e-commerce brands
MVP Sprint
6-10 weeks
Pre-seed / seed founders
How a Sanity build maps to these numbers
A content or marketing site on Sanity with a Next.js or Astro front end maps to the Starter, Launch or Growth tier by scope; a larger content platform, a bespoke Studio, or a migration onto Sanity is scoped as part of our web design and development service. One honest note on cost: our fee is for the build. The Content Lake is Sanity's hosted service, billed by Sanity on a free-then-usage-based plan, and you pay Sanity directly for it - we take no markup. We help you model editor headcount and traffic up front so there are no surprises.
See full package details on pricing and our web development service.
Sanity development, answered
What is Sanity, and what is structured content?
Sanity is an API-first, headless CMS: it stores and serves your content but does not render your website. Structured content means your content is modelled as typed data - documents and fields with defined shapes - stored as JSON in Sanity's Content Lake, rather than as pages of HTML. Because it is data, the same article or product is authored once and served to a website, an app, an email or another surface, and queried with GROQ, Sanity's query language.
Sanity vs WordPress - what's the difference?
Different models. WordPress is a traditional, page-based CMS where a team edits whole pages through a familiar themed admin with plugins - it is often the simpler, cheaper choice for a single site one team maintains. Sanity is structured and headless: content is typed data you model in code, edited in a custom Studio, and rendered by a separate front end you build. Sanity earns its keep when content is structured and reused across surfaces, or needs custom editorial workflows. If your team just wants to edit pages in a familiar admin, we will route you to WordPress.
Is Sanity the right headless CMS for me, or should I look at another one?
It depends on your editorial model and budget, and we recommend the fit rather than a badge we hold. Sanity is a strong choice when you want schema-in-code developer control, real-time collaborative editing, and a fully customizable Studio; it sits in the same structured, headless family as options like Contentful and Strapi, which lean to different strengths. Sanity is used in production by large brands and many product teams. Because we are not a Sanity partner, we have no incentive to push it - if a different headless source or a traditional CMS fits you better, we will say so.
Is Sanity good for SEO?
Sanity itself renders nothing, so SEO is a property of the front end you put in front of it. Pairing Sanity with a fast Next.js (for app- or SEO-critical sites) or Astro (for content sites) front end gives you server-rendered, fast-loading pages with full control of metadata and structured data. On a migration, we protect SEO by mapping every URL, preserving metadata, and setting redirects before cutover. We claim the method, never a ranking outcome.
Do I own my content on Sanity, and am I locked in?
You own your content, your schema, your Studio and your GROQ queries: your content is structured JSON exportable through Sanity's CLI, and your schema and Studio are open-source and live in your own repository. What you do not own is the Content Lake, which is Sanity's hosted service you pay for. So the honest answer is not a flat 'no lock-in' - moving off any hosted platform is real work - but your content is exportable, structured data rather than a database held hostage, which is a very different risk than a closed page-builder you cannot leave.
What does Sanity cost?
Sanity has a free tier with quotas, a usage-based paid plan billed per occupied seat with no annual lock-in, and an enterprise plan. The client pays Sanity directly for the Content Lake and we take no markup, so our fee is only for the build. Because cost scales with editor seats and traffic, the honest planning move is to model those up front rather than quote a single number.
Is Sanity good with Next.js?
Yes - it is one of the most natural pairings. Sanity is API-first, so a Next.js front end reads it over GROQ from server components, uses on-demand revalidation to refresh only the routes an edit affects, and shows editors in-context live preview. Sanity Studio is itself a React application, which is our core stack. That adjacency is why Sanity is the headless CMS we reach for with Next.js - and it is exactly how this site works: our blog, guides and glossary are Sanity content rendered by a Next.js front end.
Does this website run on Sanity?
The part of it that is content does. This site is a static Next.js and React build, and everything under Resources - the blog, the guides and the glossary - is modelled in a Sanity Studio, stored in the Content Lake and queried over GROQ. It is our home ground because the Studio is a React app, and rather than just recommend Sanity we put our own content on it, so what you read there is the result. The marketing, service and technology pages are code, not Sanity - we won't overstate it - but the resource library is genuinely Sanity-powered.
Do I own the code you build?
Yes - the code is yours. Your Sanity schema, your custom Studio and your GROQ queries are standard, open Sanity in your own repository, so any competent Sanity developer can take them over, and you can move on without asking us. The one hosted piece is the Content Lake, Sanity's service you pay for directly. Fixed pricing and code you own outright are the whole point.
Ready to model your content on Sanity?
Get a fixed-price quote for a Sanity build - structured content, a custom Studio, and a fast Next.js or Astro front end that reads it, with content and schema you own outright. And if a traditional CMS fits you better, we will tell you that first.