Sanity rewards careful schema design. And punishes hurried ones.

Greenfield Sanity and Next.js builds, multilingual setups, and migrations from WordPress, Contentful or Strapi. Every engagement starts with a week on the schema, because that is the decision the whole build rests on.

Plan the schema See all services

schemas/product.ts

Sanity v3

import { defineField, defineType } from 'sanity'

export default defineType({
  name: 'product',
  title: 'Product',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: r => r.required() }),
    defineField({ name: 'slug',  type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'line',  type: 'reference', to: [{ type: 'productLine' }] }),
    defineField({ name: 'body',  type: 'array', of: [
      { type: 'block' },
      { type: 'animatedDiagram' },     // schema-connected component
      { type: 'projectReference' },    // referenced content
    ]}),
    defineField({ name: 'i18n', type: 'object', fields: [
      { name: 'de', type: 'localizedBody' },
      { name: 'en', type: 'localizedBody' },
    ]}),
  ],
})

What you get

Six engagements

Each engagement starts with a week on the schema. Anyone who skips that step is selling you a content migration project they do not know they are selling.

Greenfield Sanity + Next.js

Corporate, B2B, editorial sites. Visual editing via the Presentation tool, draft mode in App Router, typed schemas with custom validation.

Multilingual setups

Schema-level i18n, language-aware routing, fallback chains. Shipped in production across German / English with two product lines.

Migration into Sanity

From WordPress, Contentful, or Strapi. Content remap, URL preservation, redirect engineering at the edge. SEO equity preserved.

Custom schema design

References vs portable text vs nested objects vs singletons. We argue about it at Week 1 because Week 12 is when bad calls hurt.

Sanity Studio extensions

Custom input components, validation rules, preview panes that show how content will actually render. Editors do not have to guess.

Component-as-content patterns

Schema-connected interactive components: animated diagrams, slideshows, click-to-play media, editor-configurable without redeploying the frontend.

The schema cost curve

Why we spend Week 1 on the schema, not the components

Cost of a schema-touching change, traced across the first months of a Sanity build. Good schemas stay flat. Hurried ones go exponential as content accumulates.

Timeline	Schema designed properly	Schema designed in a hurry
Week 1	Schema argued through before content exists	Schema rushed to start entering content sooner
Week 4	First content entered against a stable model	First content entered, gaps already showing
Week 10	Additions slot in, no remap	First migration needed as structure shifts
Week 16	Editors keep shipping	First manual remap by editors across live pages
Week 22	Schema still flat to change	First reference cycle bug, cost goes exponential

Evidence

Multi-level corporate Sanity build, two languages, two product lines

Greenfield Sanity + Next.js build in German and English for a corporate rail infrastructure firm. Original sitemap defined services up to three levels deep.

Post-sign-off, a fourth level appeared across two product lines (Long Distance Freight Track and Urban Transit: Betonschwellen, Feste Fahrbahn, Schotteroberbau, Rheda variants), forcing a Sanity schema rebuild, new page-mapping logic, and manual content entry across roughly two dozen new pages.

Plus a Project Reference table with 23 entries, each its own schema and content. Plus schema-connected interactive components: animated diagram, Sanity-connected slideshow on the Project Reference page, click-to-play video on Plants and Construction with muted preview and click-for-sound.

The point: schema rework cascades through content already entered. Once content is in production against a schema, restructuring that schema is a content-migration project, not a code change. We learned to quote schema-changing scope changes separately because we have lived the cost of getting it wrong.

Pair with headless WordPress (the WP alternative for buyers staying in WP), SaaS web app development, and technical SEO for the schema migration's URL-equity work.

Good fit if

When Sanity earns its place

Corporate / B2B sites with structured product lines, multilingual delivery, multi-level navigation
Editorial teams mature enough to live in Sanity Studio and benefit from a real content model
Multilingual builds where the content model needs to express language at the schema level
Operators migrating off WordPress / Contentful / Strapi who want structured content, not blob HTML

Probably not a fit

When the Studio overhead is not worth it

Marketing sites where a tuned WordPress theme is faster and cheaper
Small teams where the Studio overhead exceeds the editorial gain
Sites with no plan for who owns schema evolution six months from now

Stack we ship on

Sanity Studio v3 paired with Next.js App Router.

CMS

Sanity v3, Studio v3, TypeScript schemas, GROQ queries

Frontend

Next.js (App Router), React Server Components, draft mode, ISR

Visual editing

Sanity Presentation tool, live preview, click-to-edit overlays

Media

Sanity assets, image pipeline with hotspot/crop, Cloudflare edge cache

Deploy

Vercel / self-hosted on AWS, preview deployments per branch

Sanity CMS

Bring the sitemap and the content model. We'll spend Week 1 making sure they fit.

Plan the schema hello@appycodes.com