DEV Community: Nayan Kyada

Migrate Next.js Pages Router to App Router: A Buyer's Guide

Nayan Kyada — Fri, 16 Oct 2026 09:09:47 +0000

If you need to migrate a Next.js Pages Router site to the App Router, the good news is that you almost never have to do it all at once. Next.js lets both routers live in the same project, so a Sanity-powered marketing site can move one route at a time while staying live and ranking. The real questions are whether it is worth doing, in what order, and what can go wrong with search traffic.

If you are coming from Gatsby instead, that is a different path, covered in migrating Gatsby to the Next.js App Router.

When the migration is worth it

The Pages Router is not broken. A site on it that is fast, stable and easy for editors to use does not need a rewrite for its own sake. I would migrate when one or more of these is true:

Client JavaScript is heavy because every page hydrates in full, and Core Web Vitals (especially INP) suffer for it.
You want streaming, Suspense boundaries, or partial prerendering, which only exist in the App Router model.
New features keep fighting the old structure: nested layouts, per-section loading states, or draft preview done awkwardly with the older preview mode.
Hiring is getting harder. Most developers now learn the App Router first, and library docs have moved that way.
You are about to do a redesign or CMS change anyway, so the routing work rides along with work you are already paying for.

I would not migrate just because a blog post said you should. If the site earns money and nothing above applies, leave it alone and put the budget into content or a performance and Sanity audit, which starts from $800 and tells you what is actually slow.

The incremental route-by-route strategy

The safe approach is boring on purpose. You add an app directory next to pages, move routes across in order of risk, and never change a URL.

Upgrade first, migrate second. Get to Next.js 16 and React 19 on the existing Pages Router code. Fix upgrade breakage separately so you know what caused what.
Create the root layout. The app/layout.tsx file replaces _app and _document. Move fonts, global CSS and analytics there.
Move low-risk routes first. A privacy policy, a contact page, a 404. These prove the layout, styling and metadata setup without risking revenue pages.
Move templated content next. Blog posts and landing pages built from Sanity documents. One template covers hundreds of URLs, so this is where the payoff is.
Move complex routes last. Search, forms, authenticated areas, anything with heavy client state.
Delete the old file the moment the new one ships. A URL cannot be served by both routers, and the build will complain if you forget.

Each step is a separate deploy with its own staging URL. If a route misbehaves, you revert one file, not a quarter of work.

Data fetching changes with Sanity

This is where most of the actual rewriting happens. In the Pages Router you fetch in getStaticProps and pass props down. In the App Router, a server component fetches directly and the data never has to be serialised into page props.

Before:

// pages/blog/[slug].tsx
import type { GetStaticProps, GetStaticPaths } from 'next'
import { client } from '@/sanity/client'

const query = `*[_type == "post" && slug.current == $slug][0]{title, body, publishedAt}`

export const getStaticPaths: GetStaticPaths = async () => {
  const slugs: string[] = await client.fetch(`*[_type == "post"].slug.current`)
  return { paths: slugs.map((slug) => ({ params: { slug } })), fallback: 'blocking' }
}

export const getStaticProps: GetStaticProps = async ({ params }) => {
  const post = await client.fetch(query, { slug: params?.slug })
  if (!post) return { notFound: true }
  return { props: { post }, revalidate: 60 }
}

After:

// app/blog/[slug]/page.tsx
import { notFound } from 'next/navigation'
import { client } from '@/sanity/client'

const query = `*[_type == "post" && slug.current == $slug][0]{title, body, publishedAt}`

export async function generateStaticParams() {
  const slugs: string[] = await client.fetch(`*[_type == "post"].slug.current`)
  return slugs.map((slug) => ({ slug }))
}

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params
  const post = await client.fetch(query, { slug }, { next: { tags: ['post'] } })
  if (!post) notFound()
  return <article>{/* render post */}</article>
}

Three things change that clients should know about. First, params is now a promise in current versions, so every dynamic route needs an await. Second, time-based revalidate is replaced by tag or path revalidation, which pairs well with Sanity webhooks; see Sanity webhooks with ISR revalidation. Third, draft preview moves to Draft Mode, covered in Sanity Live Preview in the App Router. Editors will notice preview behaviour, so test it with them, not just with a developer.

GROQ queries themselves usually do not change at all. That is the nice part: the content layer stays put while the rendering layer is replaced.

SEO risks: metadata and canonicals

Search traffic is the thing a migration can actually lose. The risks are specific and checkable.

Metadata. next/head does not work in the App Router. Each route needs generateMetadata or a static metadata export. A route that moves without one ships with no title or description, and nobody notices until rankings slip.
Canonicals. Set alternates.canonical explicitly per route. Do not rely on defaults, especially on paginated or filtered pages, and keep trailing-slash behaviour the same as before.
Structured data. JSON-LD that lived in a head component has to be rendered in the page body now. See JSON-LD in Next.js.
Redirects and status codes. Missing documents must return a real 404 through notFound(), not a 200 with an error message.
Sitemap and robots. Move these to the sitemap.ts and robots.ts file conventions and diff the output against the old files.

A simple generateMetadata looks like this:

// app/blog/[slug]/page.tsx
import type { Metadata } from 'next'

export async function generateMetadata({
  params,
}: {
  params: Promise<{ slug: string }>
}): Promise<Metadata> {
  const { slug } = await params
  const post = await client.fetch(
    `*[_type == "post" && slug.current == $slug][0]{title, seoDescription}`,
    { slug }
  )
  return {
    title: post?.title,
    description: post?.seoDescription,
    alternates: { canonical: `/blog/${slug}` },
  }
}

Before each route goes live, crawl staging and production and compare title, description, canonical, robots meta, H1 and structured data. A spreadsheet diff catches nearly everything.

Effort ranges by site size

These are rough ranges from general practice, not quotes. Complexity matters more than page count, because a hundred posts on one template is cheap and ten bespoke interactive pages is not.

Site size	Typical scope	Effort
Small (5 to 15 routes)	Marketing pages, a blog, a contact form	1 to 2 weeks
Medium (15 to 60 routes)	Several templates, Sanity-driven pages, preview, redirects	3 to 6 weeks
Large (60+ routes or app features)	Search, auth, i18n, custom API routes, heavy client state	2 to 4 months, often phased

Things that push you up: internationalised routing, a lot of getServerSideProps logic, API routes that should become route handlers, a UI library that does not support server components, and no tests. Things that push you down: a clean Sanity schema, TypeScript throughout, and a staging environment that already exists.

What to ask a developer

Will every URL stay identical, and how will you prove it?
How will you compare metadata and canonicals before and after each route?
Which routes move first, and why those?
How does draft preview work for editors afterwards?
Can we deploy and roll back route by route?
What do you do about client-side libraries that break in server components?

A good answer is specific and mentions crawling staging. A vague answer about modernising the stack is a red flag.

Work I do

This is work I do: incremental App Router migrations on Sanity and Next.js sites, with an SEO diff on every route. If your site needs a rebuild alongside it, see my Sanity and Next.js build and migration packages, or start with an audit to size the job.

Take Over an Existing Next.js Project After Your Developer Disappears

Nayan Kyada — Thu, 15 Oct 2026 09:16:09 +0000

You own a Next.js and Sanity site, and the person who built it has stopped replying. You need to take over the existing Next.js project without breaking what is live, and without finding out three weeks in that the Sanity project belongs to someone's personal email. This is the order I work in: access first, then a read-only audit, then a decision about repair or rebuild.

Get ownership sorted before anyone writes code

The code is the least urgent part. Accounts are what can lock you out, so list every system the site touches and write down who the owner is on each one.

System	What to confirm	Who must be owner
Domain registrar	Account email, auto-renew, registrar lock	Your company
DNS	Where nameservers point, who can edit records	Your company
Git host	Repository owner, branch protection, collaborators	Your organisation
Vercel (or other host)	Team vs personal account, billing owner, env vars	Your team
Sanity project	Administrator role, API tokens, CORS origins	At least two of your people
Email and forms	SendGrid or similar, sender domain, API keys	Your company
Analytics and Search Console	Property owners	Your company

The domain is the one that matters most. If the registrar account is yours, you can always repoint the site. If it is not, fix that before anything else.

Vercel

Check whether the project lives under a team or under the developer's personal account. A project in a personal account can usually be transferred to a team, but this requires the developer's cooperation or a support request. If you cannot get that, the fallback is deploying the repository to a new project under your team and moving the domain across. That is why having the code matters.

Sanity

Only an administrator can add members or change roles. Open the project's members page in the Sanity management console and see who holds that role. If it is only the departed developer, contact Sanity support with proof of business ownership. Do not wait: the content is the one asset you cannot regenerate from a repository.

While you are there, list the API tokens. Anything with write access that you did not create should be rotated once you have control. Check the CORS origins and the webhook list too; stale webhooks pointing at old preview URLs are common.

The repository

If the repo is in your organisation, good. If it is in the developer's personal account, ask for a transfer or a full mirror including all branches and tags. If you have neither, look for the code in the hosting provider: Vercel keeps deployments, and the connected Git repository is shown in project settings. That tells you where to look, even if it does not give you access.

The first-week audit checklist

The audit is read-only. Do not upgrade packages, do not clean up, and do not push to the production branch. You are building a picture of risk.

Can it run locally? Clone, install, copy env vars from the host, start the dev server. If this takes more than a day, that is already your answer about maintainability.
Can it build in CI or on Vercel from a clean checkout? A site that only deploys from one laptop is a liability.
Which Next.js version and router? Note the major version, whether it uses the App Router, Pages Router, or both, and whether the build output shows pages that are statically generated or fully dynamic.
What does the content model look like? Open the Studio and read the schema folder. Count document types, check for unused ones, and check whether references are used or content is duplicated.
Environment variables. List every one the app reads. Mark which are secrets and which are missing from the host.
Data fetching. Search for how GROQ queries are written and whether the client uses the CDN.
Revalidation. Find out how content updates reach the live site: webhooks, time-based revalidation, or nothing.
Performance baseline. Run Lighthouse and look at field data in Search Console. Record it before you touch anything so you can show improvement later. My post on Core Web Vitals monitoring covers the setup.
SEO state. Check the sitemap, robots, canonical tags, and redirects.

A quick way to start the inventory:

# run from the repo root
git log --since="12 months ago" --pretty=format:"%an %ad %s" --date=short | head -50
grep -rn "process.env" src app lib --include=*.ts --include=*.tsx | sed 's/.*process.env.//' | cut -d' ' -f1 | sort -u
npm outdated

The git log tells you whether work was steady or abandoned, the grep gives a rough env var list, and npm outdated shows how far behind dependencies are.

Red flags in an inherited Next.js and Sanity codebase

None of these is fatal alone. Several together should change your plan.

No lockfile, or two of them. Builds are not reproducible.
Secrets committed to the repo. Rotate them immediately, whatever else you decide.
A Sanity write token used in client-side code. Anything prefixed for the browser is public.
Hard-coded content in components while the Studio holds unused equivalents. Editors will change things that do nothing.
Fetching everything on every request with no caching strategy, which usually shows up as slow pages and a large Sanity bill. See avoiding N+1 queries with Sanity references.
No types. Plain JavaScript with unvalidated query results means every change is a guess. TypeGen fixes much of this, as in fully typed GROQ queries.
A very old Studio. If the Studio is on v2 or v3, it needs to move to the current major. The path is in the Studio upgrade post.
No preview or an exposed one. Draft content visible to anyone with the URL is a quiet but real problem.
Dozens of unused document types that confuse editors and slow the Studio.

A useful check for the token problem:

grep -rn "SANITY_API_TOKEN\|NEXT_PUBLIC_.*TOKEN" . --include=*.ts --include=*.tsx --include=.env* -I --exclude-dir=node_modules

Any token with a NEXT_PUBLIC_ prefix is shipped to every visitor.

Rebuild or repair

I decide this on four questions, not on how much I dislike the code.

Repair when the site runs locally, builds cleanly, uses a reasonable content model, and the pain is limited to performance, a few bugs, or missing features. Upgrading Next.js and fixing hot spots is cheaper than a rebuild nearly every time.

Repair the Studio, rebuild the front end when the content is healthy but the Next.js code is a tangle. The Sanity dataset is the valuable asset. A new front end can read the same content with better queries. This is the most common outcome I see.

Rebuild both when the schema is the problem: duplicated content, no references, fields named after pages rather than meaning. Migrating content into a clean model costs more up front, but it stops every future change from being expensive.

Move platforms when the site is on Gatsby; see migrating Gatsby to the App Router.

If you are comparing the cost of a rebuild against a series of patches, be wary of anyone who quotes without opening the codebase.

What to ask a developer before they touch it

Will you audit before quoting, and will the audit be written down?
Where will work happen: a staging URL and a branch, not production?
Who will own the accounts at the end?
How will you handle secrets you find in the repo?
What is the rollback plan if a deploy goes wrong?

The proposal evaluation guide covers the contract side.

Work Nayan does

Taking over abandoned Next.js and Sanity sites is work I do. A fixed-price performance and Sanity audit starts from $800 and gives you the written risk list, account ownership steps, and a repair-or-rebuild recommendation before you commit to anything larger.

Contentful to Sanity Migration: How I Move Content, Assets and Locales

Nayan Kyada — Wed, 14 Oct 2026 09:38:11 +0000

A contentful to sanity migration is mostly a data-mapping exercise with a few sharp edges: rich text, assets, and locales. Done as a script you can re-run, it is low drama. Done by hand in a CMS UI, it becomes a month of copy-pasting. This is the order I work in.

When the Contentful bill is the trigger

Most migrations I see start with an invoice, not a technical complaint. A site outgrows the free tier, hits the jump to a paid plan, or needs a second environment or more locales, and the number stops making sense. If that is your situation, read Contentful pricing in 2026 first so you know exactly which limit you hit, and then Sanity vs Contentful for Next.js to check cost is not the only reason you are moving. Cost alone is a fine reason, but it should not be the only input into how you remodel content.

Step 1: Export and audit what you have

Use the Contentful CLI to export a space to JSON. That file contains content types, entries, assets and locales. Before writing any code, list every content type and mark each one: keep, merge, or drop. Migrations are the one moment you can delete the dead types nobody has touched in two years.

I produce a simple spreadsheet: content type, entry count, fields, which pages use it. Anything with zero entries or no front-end consumer gets dropped.

Step 2: Map the content model

Contentful models map onto Sanity schemas fairly directly, but a few concepts change shape.

Contentful	Sanity
Content type	Document type or object type
Short text / long text	string / text
Rich text	array of block (Portable Text)
Media (asset)	image or file field
Reference (link to entry)	reference
Many references	array of references
Locale per field	Field-level or document-level i18n
Entry ID	Document _id you control

The main decision: which Contentful types become standalone documents and which become inline objects. A Contentful "Hero" entry referenced by one page is almost always better as an object inside the page. Reusable things like authors and categories stay as documents. Structure this with query cost in mind; avoiding query waterfalls covers the reasoning.

Step 3: Use deterministic IDs

The single most useful trick is generating Sanity document IDs from Contentful IDs. That makes the import idempotent, so you can re-run it as often as you like, and references can be written before the target document exists.

// scripts/migrate/ids.ts
export const docId = (type: string, contentfulId: string) =>
  `${type}-${contentfulId}`

export const refTo = (type: string, contentfulId: string) => ({
  _type: 'reference',
  _ref: docId(type, contentfulId),
  _weak: true,
})

I mark references weak during import so ordering does not matter, then strengthen them once everything has landed.

Step 4: Convert rich text to Portable Text

Contentful rich text is a tree: a document node with block children (paragraph, headings, lists, quotes, embedded entries), and text nodes carrying marks like bold or italic. Portable Text is a flat array of blocks with spans. The conversion is a recursive walk.

// scripts/migrate/richText.ts
import { randomUUID } from 'node:crypto'

type CfNode = {
  nodeType: string
  value?: string
  marks?: { type: string }[]
  data?: any
  content?: CfNode[]
}

const markMap: Record<string, string> = {
  bold: 'strong',
  italic: 'em',
  underline: 'underline',
  code: 'code',
}

const styleMap: Record<string, string> = {
  paragraph: 'normal',
  'heading-2': 'h2',
  'heading-3': 'h3',
  'heading-4': 'h4',
  blockquote: 'blockquote',
}

function spans(nodes: CfNode[] = [], markDefs: any[]) {
  return nodes.flatMap((n) => {
    if (n.nodeType === 'text') {
      return [{
        _type: 'span',
        _key: randomUUID().slice(0, 8),
        text: n.value ?? '',
        marks: (n.marks ?? []).map((m) => markMap[m.type]).filter(Boolean),
      }]
    }
    if (n.nodeType === 'hyperlink') {
      const key = randomUUID().slice(0, 8)
      markDefs.push({ _type: 'link', _key: key, href: n.data.uri })
      return spans(n.content, markDefs).map((s: any) => ({
        ...s,
        marks: [...s.marks, key],
      }))
    }
    return spans(n.content, markDefs)
  })
}

export function toPortableText(doc: CfNode) {
  return (doc.content ?? []).flatMap((node) => {
    const style = styleMap[node.nodeType]
    if (!style) return []
    const markDefs: any[] = []
    return [{
      _type: 'block',
      _key: randomUUID().slice(0, 8),
      style,
      markDefs,
      children: spans(node.content, markDefs),
    }]
  })
}

This handles paragraphs, headings, quotes, bold, italic and links. Lists, tables, embedded entries and embedded assets need their own branches: lists become blocks with listItem and level, embedded entries become custom block objects. I deliberately skip unknown node types in this sketch, but in a real run you should log them, because silent drops are how content goes missing. Rendering the result is covered in Portable Text custom components.

Step 5: Move assets

Contentful assets have a URL per locale. Download each file once, upload it to Sanity with the client, and keep a map from Contentful asset ID to Sanity asset ID. Then, when converting entries, replace each asset link with an image field pointing at that asset ID.

// scripts/migrate/assets.ts
import { createClient } from '@sanity/client'

const client = createClient({
  projectId: process.env.SANITY_PROJECT_ID!,
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN!,
  apiVersion: '2026-01-01',
  useCdn: false,
})

export async function uploadAsset(url: string, filename: string) {
  const res = await fetch(url.startsWith('//') ? `https:${url}` : url)
  const buffer = Buffer.from(await res.arrayBuffer())
  const asset = await client.assets.upload('image', buffer, { filename })
  return asset._id
}

Throttle uploads and cache the ID map to disk so a failed run resumes instead of starting over. Add alt text to the image fields in the new schema; Contentful asset descriptions are a good source for it.

Step 6: Handle locales

Contentful stores every locale inside each field. Sanity gives you two sensible options: field-level translations for small sites, or one document per language using the document internationalization plugin for larger ones. For editorial sites with divergent content per market I prefer one document per language. Write a script that splits each Contentful entry into one document per locale, with a shared language field and deterministic IDs like page-abc123-en. The front-end side is covered in multilingual Sanity content with next-intl.

Step 7: Run the import as a transaction batch

Build an array of documents, then write them in batches using createOrReplace so reruns overwrite instead of duplicating. Import into a separate dataset first, such as staging, and let editors review there. Only copy to production when the checks pass.

Step 8: Build the redirect map

Export every live URL from your sitemap and analytics, then map each to its new path. If you keep slugs identical, most of the map is empty, which is the ideal outcome. Where paths change, add permanent redirects in the Next.js config or in middleware. Crawl the old URL list against the new site after launch and confirm every one returns either a 200 or a single 301 hop.

Step 9: Plan the cutover

My cutover order is: freeze edits in Contentful, run the final import, run the redirect and link crawl, switch DNS or the production deployment, then keep Contentful on its plan for a couple of weeks as a fallback before cancelling. Configure webhook revalidation before launch so editors see changes immediately.

If you want this handled end to end, my fixed-price migration to Sanity starts from $3,000, with details at services and packages.

Sanity Studio v2 to v3 upgrade (and on to v6): what breaks and how to fix it

Nayan Kyada — Tue, 13 Oct 2026 12:00:44 +0000

If your team is still on Sanity Studio v2, you are running a legacy Studio that Sanity no longer develops. The Sanity Studio v2 to v3 upgrade is the hard part — the configuration model, plugin API, and custom input system were all rewritten — but in 2026 you should not stop at v3. The current major version is v6, and once you have done the v3 rewrite, the remaining steps are small. This post covers what breaks, what the risk of waiting is, how to approach the migration, and what to ask a developer before hiring someone to do it.

Why v2 is no longer safe to leave alone

Studio v2 no longer receives updates. It is a deployed web app — self-hosted or at yourproject.sanity.studio — built on an older React version and older build tooling, and those dependencies keep accumulating known vulnerabilities with nobody patching them. Your content is stored in Sanity's cloud and is not directly at risk, but the Studio is an authenticated surface: a vulnerability that allows script injection in the editor UI could let an attacker act as a logged-in editor.

Beyond security, everything new in Sanity is built for the modern Studio. AI Assist, the Presentation tool for live preview, Sanity TypeGen, auto-updating Studio deployments, and the improved search all require v3 or later. Every month on v2 is a month your editors go without them.

What actually breaks in the v2 to v3 upgrade

The v2 to v3 jump is a ground-up rewrite of the Studio. The Content Lake API did not change — your GROQ queries, your dataset, and your documents are untouched. What changed is everything from the configuration layer up.

Configuration format. v2 used a sanity.json manifest and a plugin-based folder structure. The modern Studio uses a single sanity.config.ts file with a defineConfig() call. There is no automatic converter from one to the other.

Desk structure. The v2 desk tool is now the Structure tool: structureTool() imported from sanity/structure. The structure builder (S.list(), S.documentTypeList(), .child()) will look familiar, but you register it through the plugin's structure option instead of a parts override, and any custom panes need testing. If you have a complex desk, my notes on custom ordering and grouping in Structure Builder apply directly.

Plugins. Every v2 plugin needs a modern equivalent. Common ones like Vision (@sanity/vision) have been rebuilt, but package names, import paths, and configuration options changed, and some community plugins were never ported. Audit your plugin list early — an abandoned plugin can be the biggest unknown in the estimate.

Custom inputs. This is the most common source of pain. v2 inputs used PatchEvent and withDocument from the old form builder parts. Modern inputs are plain React components that receive props, call props.onChange(set(value)) or unset(), read other fields with useFormValue, and can wrap the default input with props.renderDefault(props). Every custom input is a rewrite, not a re-import.

Parts system gone. v2's parts system for overriding Studio internals no longer exists. Logos, navbar tweaks, and custom document views move to explicit options and component overrides in defineConfig().

Schema helpers. The sanity package exports defineType, defineField, and defineArrayMember for type-safe schemas. Plain object schemas still work, so you can convert gradually — but it is worth doing during the rewrite, because TypeGen and editor autocomplete both benefit.

Don't stop at v3: what changes on the way to v6

Once your Studio runs on the v3 configuration model, the later majors are mostly about runtime requirements. If you bootstrap the new Studio with npm create sanity@latest, you start on the current version and skip these steps entirely. If you port an existing v3 codebase, here is what each major adds:

Major	What changes	Typical effort
v4	Node.js 20.19+ (or 22.12+) to run the CLI	Minutes, if your Node.js is current
v5	React 19.2.2+ required; TypeGen renames result types for snake_case query names	Hours — check custom inputs and plugins for React 19 compatibility
v6	Node.js 22.12+; React strict mode on in development; `auth.providers` arrays replace the defaults; search defaults to the `groq2024` strategy; build moves to Vite 8	Hours, mostly testing custom inputs under strict mode

Your schemas, plugin configuration shape, and content APIs stay the same through all three. Sanity publishes a migration guide for each major, and the upgrade overview links them in order.

Upgrade path by Studio size

The effort scales with how much custom code sits on top of the default Studio.

Studio profile	Custom inputs	Custom structure	Effort estimate
Default schemas, stock plugins	0	None	2–4 hours
Several document types, 1–2 custom inputs	1–3	Basic `S.list()`	1–2 days
Large schema set, multiple custom inputs, branded UI	4+	Complex nested structure	3–5 days
Multi-workspace, custom tools, unported plugins	Many	Multiple workspaces and tool tabs	1–2 weeks

Those estimates assume someone who has done the migration before, and they include landing on v6 rather than v3. If a developer is reading the migration guides for the first time on your project, add about half again.

The upgrade sequence that works

Do not upgrade in place on the Studio your editors use every day. This sequence keeps v2 working until the new Studio has proven itself:

Branch the Studio codebase. Keep v2 deployed for editors while you work on a separate branch.
Bootstrap a clean, current Studio. Run npm create sanity@latest in a scratch folder so you start on the latest major, then port your schemas into it one document type at a time.
Port schemas first and check them with Vision. Get every schema loading and query real documents before touching any UI customisation. Schemas are the lowest-risk layer — and a good moment to prune document types nobody uses.
Rebuild the structure. Recreate your desk with structureTool() and test each list and nested pane.
Rewrite custom inputs one at a time. Each is a self-contained rewrite; test it under React strict mode, which v6 turns on in development.
Replace parts overrides. Move logo, navbar, and document view customisations into defineConfig().
Let editors use it before cutover. Deploy the new Studio to a separate URL against your production dataset — the content API is the same, so both Studios can run side by side — and give your content team a week or two of real use before switching the main URL.

// sanity.config.ts — modern Studio shape (v3 and later, including v6)
import { defineConfig } from 'sanity'
import { structureTool } from 'sanity/structure'
import { visionTool } from '@sanity/vision'
import { schemaTypes } from './schemaTypes'

export default defineConfig({
  name: 'default',
  title: 'My Studio',
  projectId: 'your-project-id',
  dataset: 'production',
  plugins: [
    structureTool(), // replaces the v2 desk tool
    visionTool(),
  ],
  schema: {
    types: schemaTypes,
  },
})

The v2 equivalent was spread across sanity.json, a desk structure file, and parts declarations. One typed file is far easier to maintain.

What a rewritten custom input looks like

// schemaTypes/inputs/SlugPreviewInput.tsx — modern custom input pattern
import { useFormValue, type StringInputProps } from 'sanity'

export function SlugPreviewInput(props: StringInputProps) {
  const title = useFormValue(['title']) as string | undefined

  return (
    <div>
      {props.renderDefault(props)}
      {title && (
        <p style={{ fontSize: 12, color: '#888', marginTop: 4 }}>
          Slug preview: {title.toLowerCase().replace(/\s+/g, '-')}
        </p>
      )}
    </div>
  )
}

The v2 version of this input would have reached for PatchEvent and a withDocument wrapper, neither of which exists in the modern Studio. For a fuller example, see how I build a custom input with a colour picker.

What to ask a developer before hiring

If you are scoping this work with a freelancer or agency, these questions separate someone who has done it from someone learning on your budget:

Will you land us on the current major version, or stop at v3 — and why?
Can you show me a modern sanity.config.ts from a project you have shipped?
How will you handle the custom input rewrite, and how will you test it?
Which of our plugins have no modern equivalent, and what is the plan for each?
Will editors use the new Studio against production content before cutover, and is v2 kept as a fallback?

A developer who has done this before will answer all five without hedging — especially the plugin question and the rollback plan.

The cost of another six months on v2

Every month on v2 is another month of unpatched dependencies, another month without AI Assist, Presentation, or TypeGen, and more schema debt to untangle later. The upgrade is not trivial, but it is bounded work — usually days, not months, even for a Studio with custom inputs and a structured desk.

This is work I do for teams on Sanity, from a quick performance and Sanity audit that maps your Studio and plugins to a full fixed-price migration. If you have a v2 Studio — or inherited one and are not sure what state it is in — that audit is the fastest way to get a real estimate.

Migrate Gatsby to Next.js App Router: what the path actually looks like

Nayan Kyada — Mon, 12 Oct 2026 12:16:51 +0000

If you're trying to migrate Gatsby to Next.js and you've landed here after a failed npm install or a Node version conflict, you're not alone. Gatsby's plugin ecosystem quietly rotted over the past two years, and most teams are now sitting on sites they can't upgrade, can't deploy cleanly, and can't hand to a junior developer without a full briefing on which workarounds hold the whole thing together.

This post covers the migration path I've used on real Gatsby + Sanity projects — what breaks, what carries over, and how to protect your URLs and your editors when you make the jump.

The symptoms that tell you it's time

The clients who reach me at this point usually describe the same cluster of problems:

Node 18 or 20 breaks the build. gatsby-plugin-sharp, gatsby-source-sanity, or something deeper in the Gatsby bootstrap throws on modern Node. The workaround is pinning Node 16 in .nvmrc and hoping the hosting platform still supports it.
Plugin PRs go unanswered. Gatsby is technically "in maintenance mode" but in practice that means bugs sit open and the people who maintained the plugins have moved on.
Build times are painful. Cold builds on a mid-size Sanity-backed Gatsby site often run 8–15 minutes because Gatsby pulls every document into a local GraphQL layer at build time.
Incremental builds broke silently. The promise of Gatsby's incremental cache worked sometimes, in some CI environments, and now it mostly doesn't, and nobody can tell you why.
The Studio is fine but the front end is the problem. Sanity v3 Studio is perfectly healthy — it's the Gatsby front end that's the liability.

The cost of staying is real and it compounds. Every month you stay on a Node 16 pin is a month further from being able to adopt anything new. Every plugin update you skip because it might break the build is technical debt that lands on whoever inherits the codebase next.

What a Gatsby + Sanity site actually looks like under the hood

Before I get into the migration, it's worth saying what you're actually dealing with. A typical Gatsby + Sanity site has:

gatsby-source-sanity pulling documents into Gatsby's GraphQL data layer
Page creation in gatsby-node.js using createPage against GraphQL queries
Image handling through gatsby-plugin-image with Sanity's image source
A mix of static pages and dynamically generated routes under a handful of URL patterns (/blog/:slug, /case-studies/:slug, etc.)

The good news: Sanity itself is portable. Your schemas, your content, your Studio — none of that is coupled to Gatsby. You're migrating the rendering layer, not the CMS.

The migration path I actually use

Phase 1: Audit before you touch anything (week 1)

I start by crawling the live site with a tool like wget --spider or Screaming Frog to get a complete URL inventory. Every path that exists in production goes into a spreadsheet. This becomes the URL parity checklist and the redirect map if anything changes shape.

At the same time, I audit the Gatsby GraphQL queries in each page template. These become the GROQ queries in the Next.js version. The data requirements are the same — the query language changes.

I also note which Gatsby plugins are doing real work versus which ones are handling things Next.js handles natively (image optimisation, font loading, sitemap). That shortens the dependency list considerably.

Phase 2: Build the Next.js shell in parallel (weeks 2–3)

I create the Next.js App Router project in a /next subdirectory of the same repo, or in a separate branch — never replacing the Gatsby project until the new one is verified. The client's Sanity project ID and dataset go straight into .env.local. The Sanity client setup is identical to any other Next.js + Sanity project.

The route structure maps like this:

// Gatsby: gatsby-node.js createPage for /blog/:slug
// Next.js App Router equivalent:
// app/blog/[slug]/page.tsx

// app/blog/[slug]/page.tsx
import { client } from '@/sanity/lib/client'
import { notFound } from 'next/navigation'

type Props = { params: Promise<{ slug: string }> }

export async function generateStaticParams() {
  const slugs = await client.fetch<{ slug: string }[]>(
    `*[_type == "post" && defined(slug.current)]{ "slug": slug.current }`
  )
  return slugs.map((s) => ({ slug: s.slug }))
}

export default async function BlogPost({ params }: Props) {
  const { slug } = await params
  const post = await client.fetch(
    `*[_type == "post" && slug.current == $slug][0]{
      title, body, publishedAt,
      mainImage{ asset->{ url, metadata { dimensions, lqip } }, hotspot, crop }
    }`,
    { slug }
  )
  if (!post) notFound()
  // render
}

This pattern replaces the entire gatsby-node.js createPage loop. generateStaticParams at build time, GROQ instead of GraphQL, notFound() instead of a 404 redirect in the Gatsby config.

Phase 3: URL parity and redirects (week 3)

Gatsby's default trailing-slash behaviour differs from Next.js. If your Gatsby site served /about/ and Next.js serves /about, search engines see them as different URLs and you'll haemorrhage rankings.

In next.config.ts, set trailingSlash: true if your existing URLs use trailing slashes, or write explicit redirects for any paths that genuinely change shape during the migration:

// next.config.ts
import type { NextConfig } from 'next'

const config: NextConfig = {
  trailingSlash: true,
  async redirects() {
    return [
      // example: Gatsby used /news/:slug, Next.js uses /blog/:slug
      {
        source: '/news/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
    ]
  },
}

export default config

Before launch I run the URL inventory from phase 1 against the new site using a script that checks every path and logs non-200 responses. No path should 404 that didn't 404 before.

Phase 4: ISR instead of long builds (week 4)

This is where the biggest operational win lands. Rather than rebuilding every page on every deploy, I set revalidate on the data fetches that change frequently, and use Sanity webhooks to trigger on-demand revalidation for specific documents when editors publish. Build times drop from 12 minutes to under 2 minutes because the static generation at deploy time only handles the shell — content updates revalidate in the background.

Phase 5: Staging review and handoff

I deploy the Next.js build to a Vercel preview URL, share it with the client for a two-week parallel run, and then do the DNS cutover once they've signed off. The Sanity Studio URL doesn't change. The editors notice nothing except that the front end is faster.

Realistic timeline

For a Gatsby + Sanity site with 5–10 content types and 200–500 pages, the migration runs 4–6 weeks: one week of audit, two weeks of build, one week of URL/redirect verification, one week of staging review. More complex sites with e-commerce, internationalisation, or heavy custom Gatsby plugins add 2–4 weeks.

What to ask a developer before you hire for this

Ask them how they handle URL parity — if they say "redirects" without mentioning a pre-launch URL audit and automated checking, that's a gap. Ask whether they'll run the Gatsby and Next.js sites in parallel before cutover, or go straight to a swap. Ask how they'll test that every editor workflow still functions post-migration. The Sanity Studio is untouched but webhooks, preview links, and any custom document actions need verifying against the new front end.

This is the kind of migration I run for clients — Gatsby to Next.js App Router, Sanity intact, URL parity confirmed before the DNS moves. If your Gatsby site is pinned to Node 16 and your builds are breaking, get in touch.

Sanity vs WordPress.org Pricing 2026: Real Hosting and Plugin Costs Compared

Nayan Kyada — Sun, 11 Oct 2026 10:57:01 +0000

Comparing Sanity vs WordPress.org pricing is harder than it looks because WordPress.org is self-hosted software — the license is free, but every cost you'd normally ignore compounds into a real number by year two. This post breaks down what each platform actually costs at small, medium, and growth scale, including infrastructure, plugins, and maintenance time you should price in.

What you're actually paying for on each platform

Sanity charges for hosted infrastructure: API requests, datasets, and seats. WordPress.org charges nothing for the software itself, but you pay for the server, database, CDN, backups, security plugins, and often a premium theme or page builder on top.

The line people miss is that Sanity's pricing is usage-based and predictable once you model your traffic. WordPress.org costs scale with the number of plugins you depend on and the hosting tier you need to stay stable under load.

Sanity pricing tiers in 2026

Sanity's current public plans:

Free: 1 project, 2 non-admin users, 500k API CDN requests/month, 20 GB bandwidth, 10 GB assets
Growth: $15/month (billed annually), 3 non-admin users included, then $10/user/month, 1M API CDN requests/month, 100 GB bandwidth, 50 GB assets
Team: $99/month, 5 non-admin users, 5M API CDN requests/month, unlimited datasets, priority support
Enterprise: custom — starts around $1,500/month based on public case studies; includes SLA, SSO, custom roles

What actually triggers an upgrade from Free to Growth: hitting the 500k CDN request ceiling or needing a third editor. For a content site doing ~30 posts/month and pulling data at build time plus client-side Sanity Live, 500k requests can go fast if you're not caching GROQ responses at the edge. Growth at $15/month is a low bar — most client projects land here by month two.

Bandwidth overage on Growth is $0.10/GB above the 100 GB cap. Asset storage overage is $0.05/GB above 50 GB. Neither is punishing at small scale.

WordPress.org cost breakdown

This is where you have to be honest. A "free" WordPress site has real line items:

Cost category	Budget tier ($/yr)	Mid tier ($/yr)	High-traffic tier ($/yr)
Managed hosting (e.g. Kinsta, WP Engine)	$300	$600–$1,200	$3,000–$6,000
Premium theme or page builder	$60–$100	$200–$400	$400 (multi-site)
Security plugin (Wordfence Pro, Solid Security Pro)	$120	$120	$120–$250
Backup plugin (BlogVault, UpdraftPlus Plus)	$120	$120	$120–$400
SEO plugin (Yoast SEO Premium, Rank Math Pro)	$99	$99	$99–$200
CDN add-on or Cloudflare Pro	$0–$240	$240	$240–$600
Performance plugin (WP Rocket, Perfmatters)	$59	$59	$59
Estimated developer maintenance (hours × rate)	$0 (DIY)	$600–$1,200	$2,000–$4,000
Annual total	$760–$860	$2,040–$3,450	$6,040–$11,650

The mid-tier number is what a real business running WooCommerce or a high-traffic blog actually pays without ever opening an enterprise conversation. The developer maintenance line is the one most cost comparisons omit — WordPress security patches, plugin conflicts, and PHP updates happen on a schedule you don't control.

Sanity annual cost at equivalent scale

Scale	Sanity plan	Annual cost
Side project or MVP	Free	$0
Small team, 2–4 editors	Growth ($15/mo × 12 + 1 extra seat)	$300
Agency or content-heavy site	Team ($99/mo × 12)	$1,188
Enterprise / multi-tenant	Enterprise	$18,000+

Add Next.js hosting (Vercel Pro at $240/yr for small teams, or a VPS at ~$120/yr) and you're at $420–$1,428/yr for small-to-medium Sanity + Next.js projects. No security patching cycle. No plugin conflicts. No PHP. Deployments are static-first with ISR revalidation on Sanity webhooks.

Where WordPress.org wins on cost

A single developer who already knows WordPress and doesn't need Sanity's structured content model can stand up a site faster with fewer moving parts. If the project is a blog where one person writes and publishes, and you're already on shared hosting you've paid for, the marginal cost of WordPress.org is genuinely near zero.

WooCommerce is also a meaningful advantage: Sanity doesn't have a native commerce layer. If you want a headless WooCommerce + Next.js setup you're adding API complexity on both ends.

Where Sanity wins on cost

At the mid tier, Sanity's cost curve is flatter. Once you're paying $1,000–$1,200/yr for Sanity Team + Vercel Pro, you've eliminated the variable plugin/security/maintenance spend that makes WordPress.org unpredictable. No CDN configuration, no uptime monitoring setup, no emergency patches when a plugin author drops a vulnerability.

For multi-locale sites or structured content that needs to be consumed by mobile apps, a CMS API, or multiple front-ends simultaneously, Sanity's GROQ API delivers what WordPress.org requires a full REST/GraphQL plugin stack to approximate.

The upgrade trigger comparison

Sanity's upgrade is API requests and seats — both are predictable. If you hit the Growth CDN ceiling, you can switch to ISR with longer revalidation windows or add edge caching in front of Sanity's API CDN to stay on the free plan longer.

WordPress.org's upgrade trigger is usually a combination of: a plugin going abandoned, a server running out of headroom during a traffic spike, or a PHP/MySQL version incompatibility after a host OS upgrade. Those are harder to model.

Which to recommend

If a client already runs WordPress, has a developer on staff who manages it, and doesn't need multi-channel structured content: stick with WordPress.org. The switching cost isn't justified.

If a client is starting fresh, needs a clean editor experience, expects a Next.js front-end, and values predictable infra costs over time: Sanity at $300/yr for a small team beats mid-tier WordPress at $2,000–$3,000/yr once you count plugins and maintenance honestly.

Sanity vs Payload CMS vs Storyblok: Pricing Comparison 2026

Nayan Kyada — Sun, 04 Oct 2026 10:41:41 +0000

Sanity, Payload CMS, and Storyblok are the three headless CMS platforms I quote most often when scoping Next.js projects in 2026. Pricing is almost always the first question, and the answer is genuinely different depending on team size, content volume, and whether you want managed hosting. This post compares real numbers — no estimates, no hand-waving.

How each pricing model works

Before the table, a quick structural note because the three models are fundamentally different.

Sanity charges on the hosted API tier. The free plan (called Free) gives you one project, unlimited admin users, 10 GB asset storage, 500k API CDN requests per month, and a dataset cap of 500k documents. Overage pricing kicks in at the dataset and API request layer — you don't pay per editor seat on Free or Growth, which is a meaningful differentiator. Growth is $15/month (billed annually) per project and raises limits substantially.

Payload CMS is open-source software you self-host. The software itself is free under MIT. "Pricing" means your infrastructure bill — a Render or Railway instance, a MongoDB Atlas or Postgres cluster, and object storage for assets. Payload Cloud (managed hosting) launched in 2024 and was revised in 2025; as of 2026 it starts at $45/month for a single project. If you self-host well, Payload can be genuinely the cheapest option. If you are sloppy, the ops cost adds up fast.

Storyblok charges per seat. The free Community plan allows one user and up to 25k API calls per month. The Starter plan is $99/month for two seats. Growth jumps to $299/month and adds more seats, spaces, and webhook triggers. Enterprise is custom. The per-seat model means a five-person marketing team on Storyblok costs real money quickly.

Side-by-side pricing table

	Sanity Free	Sanity Growth	Payload self-hosted	Payload Cloud	Storyblok Community	Storyblok Starter	Storyblok Growth
Monthly cost	$0	$15/project	~$20–60 infra	$45	$0	$99	$299
Editor seats	Unlimited	Unlimited	Unlimited	Unlimited	1	2	5
API requests/month	500k CDN	10M CDN	Self-managed	Self-managed	25k	250k	1M
Asset storage	10 GB	50 GB	Self-managed	20 GB	5 GB	25 GB	100 GB
Environments	2 datasets	Custom	Unlimited	2	1 space	3 spaces	5 spaces
Custom roles / RBAC	No	No	Yes (custom)	Yes	No	No	Yes
Webhooks	Yes	Yes	Yes	Yes	Limited	Yes	Yes

Infrastructure estimates for Payload self-hosted: $7/month Railway Starter, $9/month MongoDB Atlas M10 (minimum for production), $5/month Cloudflare R2 for assets — roughly $21/month if you stay small. A more serious setup (dedicated DB, blob storage, preview deployments) runs $50–100/month.

What actually triggers an upgrade

Sanity upgrades are triggered by API CDN requests, not seats — which makes it predictable for teams with many editors but low traffic. A marketing site with 200k monthly visitors, image-heavy pages, and ISR cache hits almost never breaches the Growth plan limits. Where you do get hit: real-time preview endpoints that bypass CDN, or a site with a lot of unauthenticated GROQ queries fired client-side. Sanity's pricing page shows overage rates at $0.50 per additional 100k API requests and $0.10 per extra GB of storage.

Payload Cloud upgrades are straightforward — you move from the $45 Starter to custom enterprise pricing when you need more compute, more environments, or SLA guarantees. Self-hosted Payload scales differently: the trigger is your own comfort level with Mongo ops and keeping up with Payload releases, not a billing threshold.

Storyblok upgrades are seat-triggered. One extra editor over the plan limit and you're on the next tier. The jump from Starter ($99) to Growth ($299) is $200/month — a significant step. Growth also unlocks granular roles (useful for separating content editors from devs) and higher API limits. If you're building a site that an agency will hand off to a five-person client team, budget for Growth from day one.

Total cost of ownership over 12 months

Here's a realistic scenario: two developers, three marketing editors, a production site, and a staging environment.

Sanity Growth: $15/month × 12 = $180/year. No seat cost. Staging uses a second dataset on the same project (within plan limits). Total: $180.
Payload self-hosted: Railway + Atlas + R2 ≈ $50/month × 12 = $600/year. Add dev time for ops — patching, backups, migration scripts. Real cost is $600 plus 4–8 hours of engineering time annually.
Payload Cloud: $45/month × 12 = $540/year. No ops burden. Competitive with Sanity Growth for small teams if you value managed infrastructure.
Storyblok Growth: $299/month × 12 = $3,588/year. Three editors push you firmly into Growth. The seat model is punishing for content-heavy teams.

For a solo founder or two-person team, Storyblok Community and Sanity Free are both usable. Past five people, Storyblok's costs compound fast. Sanity scales editors without charging for them; Payload gives you a zero-seat-cost self-hosted option if you have the ops maturity.

Which to pick based on budget constraints

Under $50/month total: Sanity Free plus Vercel hobby, or Payload self-hosted on Railway. Sanity wins on zero-config; Payload wins if you need SQL or custom auth.

$50–$150/month: Sanity Growth ($15/project) plus whatever hosting you already pay. Most real projects live here. Payload Cloud ($45) is the alternative if you prefer a unified managed service.

$150–$400/month: Storyblok Starter becomes relevant only if your team is two people and you specifically want the visual editor experience. Otherwise, Sanity or Payload still beat it on cost for equivalent functionality.

Over $400/month: You're looking at Storyblok Growth or Sanity custom/enterprise. At this scale, seat count and environment limits matter more than per-unit costs — get quotes from each vendor directly.

The short version: Sanity wins on predictable low cost for multi-editor teams. Payload wins on long-run cost if you're self-hosting and have ops capacity. Storyblok wins on editor UX, not pricing.

Sanity vs Payload CMS vs Contentful: Pricing Comparison 2026

Nayan Kyada — Sat, 03 Oct 2026 09:58:17 +0000

Sanity, Payload CMS, and Contentful pricing in 2026 looks radically different depending on how you count. Sanity charges per seat plus usage, Payload is open-source but carries real infrastructure costs, and Contentful's jump from free to its first paid plan is steep. This post puts all three side by side with real numbers so you can make an informed decision before you commit.

Why these three get compared

These are the three CMS options I see shortlisted most often for Next.js App Router projects. Sanity is the structured-content default for most greenfield work. Payload is the choice when teams want an open-source, self-hosted option with a proper TypeScript-native schema layer. Contentful is the incumbent — huge enterprise penetration, a recognisable brand, and pricing that surprises people the first time they see a quote.

They serve similar use cases but land in completely different cost brackets depending on your team size, traffic, and whether you want to manage infrastructure.

Sanity pricing in 2026

Sanity's Free plan gives you up to 20 seats, 2 public datasets, 10k documents, 1M API CDN requests and 250k API requests per month, 100 GB bandwidth, and 100 GB of assets. For a small marketing site or a developer experimenting, that holds for a surprisingly long time.

The Growth plan is $15 per seat per month (Viewer seats are free), up to 50 seats. It adds private datasets and raises documents to 25k, with the same 1M API CDN / 250k API request quotas, and pay-as-you-go overages: $1 per extra 250k API CDN requests, $1 per extra 25k API requests, $0.30/GB bandwidth and $0.50/GB assets (sanity.io/pricing at the time of writing).

Enterprise pricing is custom, with negotiated quotas, SLAs and dedicated support.

Note: Growth is billed per seat, so cost scales with your editing team — but because the Free plan already allows 20 seats, many small teams never need to pay for seats at all.

Payload CMS pricing in 2026

Payload itself is MIT-licensed and free. There is no per-seat cost, no API request limit tied to the CMS vendor, and no bandwidth charge from Payload. Your cost is entirely infrastructure.

Payload Cloud, the managed hosting option, is not a realistic choice for new projects right now: after Payload joined Figma (June 2025), Payload announced that deployment of new Cloud projects is paused, with existing Cloud projects kept running. Check payloadcms.com for its current status. In practice, budget for self-hosting.

If you self-host on Railway or Fly.io instead: expect $20–$60/month for a small project (shared Postgres instance + small container). Add managed Postgres from Neon or Supabase ($0–$25/month) and a CDN (Cloudflare free tier covers most cases). Total self-hosted cost for a small production project sits around $30–$80/month — you are on the hook for uptime.

Contentful pricing in 2026

Contentful's Free plan caps users, records, and monthly API calls, and the limits have changed several times — check contentful.com/pricing for the current numbers before you rely on it. It is genuinely limited for a production site with frequent revalidation.

The entry paid plan (Lite) has been listed at around $300/month at the time of writing. That jump — from $0 to roughly $300 — is the "Contentful cliff" the community has complained about for years. Above that, Premium is custom-priced.

Contentful's plans also cap spaces, environments, and locales, which matters for multi-brand or multi-region setups.

Side-by-side pricing table

	Sanity Free	Sanity Growth	Payload Self-Hosted	Contentful Free	Contentful Lite
Monthly cost	$0	$15/seat	~$30–80 infra	$0	~$300
Editor seats	Up to 20	Up to 50 (paid per seat; Viewers free)	Unlimited	Capped	Capped
API requests	1M CDN + 250k API/mo	1M CDN + 250k API/mo, then pay-as-you-go	No limit (vendor)	Capped	Higher cap
Documents	10k	25k	Depends on DB	Capped records	Capped records
Asset storage	100 GB	100 GB, then $0.50/GB	Depends on host	Capped	Capped
Bandwidth	100 GB	100 GB, then $0.30/GB	Depends on host	Capped	Capped
Hosted	Yes	Yes	No	Yes	Yes
TypeScript schemas	Yes (TS config + TypeGen)	Yes (TS config + TypeGen)	Yes (native TS)	No	No

Contentful caps change often; check its pricing page for current numbers.

What actually triggers an upgrade

Sanity: The trigger is usually private datasets, the 10k document cap, or needing pay-as-you-go headroom on API requests — not users, since Free allows 20 seats. A Next.js site revalidating dozens of routes every few minutes can eat into the 250k uncached API requests faster than you expect, so prefer the API CDN and tag-based revalidation. Moving to Growth ($15/seat/month) is low friction — the bigger risk is not watching overage costs if traffic spikes.

Payload: The trigger is infrastructure reliability, not the software. A minimal container and shared database will struggle under sustained traffic, and moving to properly sized hosting happens when you need uptime guarantees. With new Payload Cloud projects paused, teams without a DevOps person need a managed platform (Vercel plus a managed Postgres, for example) or someone to own the infrastructure.

Contentful: The trigger is hitting the Free plan's user, record, or API-call caps, which happens fast. The roughly $300/month jump is brutal for small teams. If you are a 3-person team with a modest site, you will either stay artificially small on Free or swallow a significant cost jump. There is no middle tier.

Which one is cheaper at different scales

Solo developer / tiny site: Sanity Free or Payload self-hosted. Contentful Free is too limited on API calls for a Next.js ISR setup.

5–10 editors, moderate traffic: Sanity wins on cost. Free covers up to 20 seats if public datasets and 10k documents are enough; Growth at $15/seat/month (so $75–$150/month for 5–10 paid seats) still undercuts Contentful Lite. Payload self-hosted is cheaper on paper but costs DevOps time.

15–30 editors, multi-locale: Payload self-hosted if you want no seat costs and own your data. Sanity Growth costs $225–$450/month for 15–30 paid seats (Viewers free), so it is no longer automatically the cheapest. Contentful Lite (~$300/month) only makes sense if your team is deeply embedded in the Contentful workflow and unwilling to migrate.

Enterprise / multi-brand: Contentful has the deepest enterprise tooling (Workflows, Tags, Organisations). The cost reflects that. Sanity Enterprise competes at similar price points. Payload Enterprise is an emerging option — worth evaluating if data residency or full schema control matters more than enterprise support SLAs.

The honest verdict

For most Next.js + Sanity shops reading this: Sanity Free, then Growth at $15/seat/month, is the easiest decision at small-to-medium scale. Payload makes sense when you need TypeScript-native schemas, full data ownership, and are comfortable managing infrastructure. Contentful's pricing model has not caught up with the market — the $0-to-$300 cliff is a legitimate reason to look elsewhere in 2026, not just a community gripe.

Sanity vs Payload CMS vs Directus: Pricing Comparison 2026

Nayan Kyada — Fri, 02 Oct 2026 10:37:55 +0000

Pricing for headless CMS platforms is genuinely hard to compare because each charges on a different axis — seats, API calls, bandwidth, compute, or a mix. This post puts Sanity, Payload CMS, and Directus side by side with concrete numbers so you can make a real decision before you commit to one.

Why this trio keeps coming up

These three platforms attract similar buyers: teams building structured-content sites on Next.js who want a proper content model and a developer-friendly API. But they monetise completely differently. Sanity is SaaS-hosted with a generous free tier. Payload is self-hosted open-source with an optional Cloud offering. Directus is open-source too, but its Cloud plans are priced per project and per seat. That difference shapes the total cost of ownership more than any feature spreadsheet does.

Pricing at a glance

Factor	Sanity	Payload CMS	Directus
Free tier	Free Plan: 2 non-admin users, 10 GB bandwidth, 20 GB assets, 3 projects	Community (self-hosted): unlimited — you pay infra only	Community (self-hosted): unlimited — you pay infra only
Cheapest paid SaaS tier	Growth: $15/month per project (5 non-admin users, 50 GB bandwidth)	Payload Cloud Starter: $19/month (1 project, 1 GB DB, 5 GB storage)	Directus Cloud Starter: ~$15/month (1 project, 1 seat included)
Per-seat model	Non-admin editors free on Growth; admin seats priced separately above 5	No per-seat on Cloud — per-project pricing	Yes: additional seats $7–10/seat/month depending on tier
Bandwidth overage	$0.10/GB above plan limit	Included up to plan limit; overage charged per GB	$0.10/GB above plan; Starter caps at 50 GB/month
Asset storage overage	$0.10/GB above plan limit	~$0.25/GB above plan limit	$0.10/GB above plan limit
Self-hosted option	No (Studio can be self-hosted; Content Lake is SaaS only)	Yes — MIT licence, zero licence cost	Yes — AGPL licence, zero licence cost
Enterprise pricing	Custom; typically starts north of $1,000/month	Custom; contact sales	Custom; Directus Enterprise starts around $2,000/month

Sanity pricing in practice

Sanity's free plan covers a surprising amount: three projects, 20 GB asset storage, 10 GB monthly bandwidth, and two non-admin users per project. For a small marketing site with a one-person editorial team that's genuinely zero cost — assuming you stay under the bandwidth ceiling.

The trigger for upgrading to Growth ($15/project/month) is almost always one of two things: you exceed the bandwidth cap, or you need more than two non-admin editor seats. Growth gives you 50 GB bandwidth and five non-admin users per project. Overage beyond that is $0.10/GB on bandwidth and $0.10/GB on assets — predictable enough that you can budget it.

The ceiling Sanity buyers hit most is the Content Lake API rate limits on the free plan (roughly 1,000 API CDN requests per second; unpublished draft API calls are much lower). High-traffic news sites hit this before they hit bandwidth. Growth raises those limits meaningfully.

For a Next.js site with ISR revalidation and a Sanity webhook setup, the Growth plan at $15/month is almost always sufficient until you're well past 50,000 monthly visitors.

Payload CMS pricing in practice

Payload's core value proposition is that the Community edition is free forever, self-hosted, MIT-licensed, and production-ready. You pay infrastructure — a PostgreSQL database, a file storage bucket (S3 or R2), and a compute host. A minimal Railway or Render setup runs $5–15/month. Add S3 or Cloudflare R2 for storage and you're typically under $20/month total for low-to-medium traffic.

Payload Cloud is the managed option: Starter at $19/month gives you one project with 1 GB database, 5 GB storage, and a managed deploy. The Pro plan ($49/month) moves to 10 GB DB and 50 GB storage. These are competitive numbers but the sweet spot for Payload is still self-hosted — the Cloud product is relatively new and the community tooling around self-deployment is mature.

Where Payload gets expensive is engineering time. Setting up CI/CD, database backups, storage integrations, and zero-downtime deploys requires more ops work than Sanity or Directus Cloud. For a solo freelancer or a startup without DevOps experience, that hidden cost is real.

Directus pricing in practice

Directus splits the same way: self-hosted Community (AGPL, free) vs Directus Cloud. The AGPL licence means if you modify Directus and expose it as a service, you must open-source those modifications — that's a dealbreaker for some SaaS products but irrelevant for most content-site use cases.

Directus Cloud Starter is around $15/month for one project and one included seat. Additional editors cost $7–10/seat/month, which is the most common cost complaint. A 10-person editorial team would pay $15 + (9 × $8) = $87/month minimum on Starter — before hitting bandwidth or storage limits. That adds up faster than Sanity for editor-heavy newsroom setups.

The self-hosted route avoids per-seat costs entirely. A DigitalOcean or Railway instance running Directus with a managed PostgreSQL database costs roughly $10–25/month, depending on traffic.

Total cost comparison at three scale points

Scale	Sanity	Payload (self-hosted)	Directus (self-hosted)	Directus Cloud
Solo dev / prototype	$0 (free plan)	~$10/month (infra)	~$10/month (infra)	$15/month
5-editor marketing site	$15/month (Growth)	~$20/month (infra + DB)	~$10–20/month (infra)	$47/month (1 + 4 seats)
20-editor content team	$15–30/month + overages	~$25–40/month (infra)	~$20–30/month (infra)	$150+/month (per seat)

Which one to pick on cost alone

If you want zero infrastructure management and have a small editorial team, Sanity's free plan or $15/month Growth tier is genuinely hard to beat. The Content Lake handles delivery, the CDN is included, and you don't touch a database.

If your team is larger than five editors or you want no per-seat charges and are comfortable with self-hosting, Payload self-hosted is the cheapest path at scale — MIT licence, low infra cost, and no surprises.

Directus Cloud becomes expensive quickly once you add editors. The self-hosted Community version is cost-competitive with Payload, but the AGPL licence needs a legal read before you deploy commercially.

The real cost inflection points: Sanity triggers at bandwidth; Payload at engineering time; Directus Cloud at seat count. Pick the one whose constraint you're furthest from.

Sanity vs Payload CMS vs Prismic: Pricing Comparison 2026

Nayan Kyada — Thu, 01 Oct 2026 11:05:02 +0000

Sanity, Payload CMS, and Prismic are three of the most searched headless CMS options for Next.js teams in 2026, and their pricing models are structured so differently that a direct comparison is harder than it looks. This post cuts through the marketing pages and maps out what each platform actually costs at three realistic scales: a solo side project, a small product team, and an agency running multiple client sites.

Why these three are hard to compare directly

Payload is self-hosted open source by default — no per-seat fee, no usage meter, but you're paying for compute and Postgres somewhere. Sanity is a managed API service with a generous free tier and a growth plan that charges on seats and dataset usage. Prismic is per-seat SaaS with a document limit twist that catches people off guard. They're solving the same problem in three different commercial structures, which makes apples-to-apples pricing non-trivial.

Sanity pricing in 2026

Sanity's free tier (called Free) gives you one project, three non-admin users, 500k API requests per month, 10 GB bandwidth, and 20 GB of storage assets. It covers most portfolio sites and small blogs indefinitely.

The Growth plan starts at $15/month per seat (minimum one seat). That seat count is what triggers most upgrades — once a content team has more than three editors, Growth is required. On Growth you get 500k API requests included and then $8 per additional 100k, plus $1/GB beyond 100 GB bandwidth. Dataset limits are relaxed significantly.

Enterprise pricing is custom but starts around $3,000/month in practice for teams that need SSO, audit logs, and dedicated support SLAs.

Payload CMS pricing in 2026

Payload's open-source version is free forever and has no seat restrictions. You run it on your own infrastructure — a $10–20/month Fly.io or Railway instance plus a Postgres database gets you production-ready. The only real cost is your time to maintain it.

Payload Cloud (the managed offering) launched post-2.0 and is positioned as a zero-ops path. Pricing runs roughly $25/month for the starter tier (1 project, 1 GB DB, 10 GB media storage), $75–100/month for a team tier with more storage and environments. These numbers have shifted in 2026 as Payload Cloud matures — check their site for current rates, but the floor is meaningfully higher than DIY infrastructure.

The ceiling difference matters: self-hosting Payload at scale is predictable cost-wise (you're paying cloud infrastructure rates), while Payload Cloud adds a margin on top. For agencies running 10+ client sites, self-hosted Payload on a shared VPS cluster is frequently the cheapest option across all three.

Prismic pricing in 2026

Prismic uses a per-seat model with a document count ceiling that surprises teams after year one. The free tier allows 1 user, 1 repository, and 1,000 documents (including every locale variant separately). That document limit is the real constraint — an e-commerce site with 500 products in two languages has already hit it.

The Starter plan is $15/seat/month with up to 10,000 documents and 3 repositories. The Professional tier runs $30/seat/month, bumps document limits to 50,000, and adds more environments and custom types. At five editors on Starter, you're paying $75/month before bandwidth or API overages.

Prismic's bandwidth pricing is not public-facing — they bundle it into plan tier rather than charging per GB. In practice this means you can't scale-test the true ceiling before committing to a higher tier.

Side-by-side cost table

Scenario	Sanity	Payload CMS	Prismic
Solo project / portfolio	Free forever	Free (self-host ~$10/mo infra)	Free (1 user, 1k docs)
3 editors, 1 site	Free tier	Free + ~$15/mo infra	$45/mo (3 seats Starter)
5 editors, 1 site	$75/mo (5 seats Growth)	Free + ~$20/mo infra OR ~$75/mo Cloud	$75/mo (5 seats Starter)
5 editors, 5 client sites	~$75/mo + per-project add-ons	Self-host ~$30–50/mo shared	$150/mo + extra repositories
Enterprise (20+ editors)	Custom (~$3k+/mo)	Self-host at scale / Cloud custom	Custom

Payload's self-hosted model wins on pure cost at nearly every scale. Sanity wins on zero-ops convenience and GROQ query flexibility. Prismic's per-seat cost converges with Sanity's Growth plan but the document limit adds a hidden upgrade trigger Sanity doesn't have.

What actually triggers an upgrade

Sanity — the trigger is almost always seat count, not API requests. Three content editors on a marketing team is the inflection point. Bandwidth overages are rare for sites under 50k monthly visitors.

Payload — on the open-source path, the trigger is ops overhead: backups, migrations, Postgres maintenance. When a client starts asking about uptime SLAs, you either pay for Payload Cloud or you productionise your own infra more seriously. On Payload Cloud, storage is the first ceiling you hit.

Prismic — document count is the stealth trigger. Multi-locale setups and large product catalogues hit the free and Starter limits faster than teams expect. The second trigger is repository count once you're running sites for multiple clients.

Which makes sense at which scale

For a solo Next.js developer building client sites, Sanity Free or a self-hosted Payload instance covers 80% of projects with minimal cost. Prismic's free tier is too restrictive on documents to be useful for real client work.

For a three-to-five person product team that wants a managed API and doesn't want to think about infrastructure, Sanity Growth is the cleanest path. The $75/month for five seats is predictable and the GROQ + Sanity Studio combination has the best developer experience of the three.

For an agency running ten or more independent client sites, self-hosted Payload on a shared cluster is typically the cheapest option by a wide margin. The open-source license has no per-site fee, and a well-configured Railway or Fly.io setup costs less per month than two Prismic seats.

For teams that need Slice Machine and a visual page builder that non-technical editors can own completely, Prismic is still the most polished option despite the seat cost — just budget for the document ceiling before you hit it in production.

Sanity vs Payload CMS vs Keystatic: Pricing Comparison 2026

Nayan Kyada — Wed, 30 Sep 2026 10:37:29 +0000

Choosing between Sanity, Payload CMS, and Keystatic almost always comes down to pricing at some point in the conversation. All three have free paths to production, but the cost curves diverge sharply once you add seats, environments, or serious traffic. Here is what you actually pay at each tier in 2026.

Why this comparison matters

Sanity is API-first, fully hosted, and charges by usage and seats. Payload is open-source and self-hosted by default, shifting cost to infrastructure. Keystatic is Git-based and pushes most cost to your Git host and optional Keystatic Cloud. They solve overlapping problems — structured content for Next.js apps — but they are not interchangeable once you account for team size, deployment complexity, and who pays the ops bill.

I've scoped projects on all three in the last twelve months. The sticker price rarely tells the full story.

Free tier limits side by side

Feature	Sanity Free	Payload Free (self-hosted)	Keystatic Free
Hosted by vendor	Yes	No	Optional (Cloud)
Datasets / projects	2 projects	Unlimited (self-host)	Unlimited repos
Users / editors	3 non-admin users	Unlimited	Unlimited
API requests	250k CDN req/month	Unlimited (your server)	Git API limits apply
Assets / storage	5 GB assets	Your own storage	Git LFS or external
GROQ / query API	Included	REST + GraphQL included	N/A (Git reads)
Environments (staging)	1 (single dataset)	Separate deploys	Branch-based
Sanity Studio hosting	Included	Self-host	Self-host

Sanity's free tier is genuinely useful for a single small project. Three non-admin users covers most founder-plus-one-editor setups. The 250k CDN request ceiling sounds large but a Next.js ISR site with moderate traffic and preview calls can brush against it faster than expected — especially once you add live preview sessions.

Payload's free tier is unlimited in every meaningful sense because you own the server. But "free" here means you are running a Node.js process somewhere. A Railway Hobby plan ($5/month), a Render free-tier instance (with cold starts), or a VPS at $6/month from Hetzner — that's your baseline, not zero.

Keystatic's free tier is genuinely zero if you stay on the open-source path and store content in your Git repo. GitHub or GitLab is the database. For most small sites, this is fine. For large content libraries (hundreds of documents with media), Git history bloat becomes a real problem.

Paid tier thresholds

Plan	Sanity	Payload Cloud	Keystatic Cloud
Entry paid	$15/month (Growth)	$25/month (Starter)	$19/month (Team)
What triggers upgrade	>3 non-admin users, >250k CDN req, >5 GB assets	Wanting managed hosting	Wanting managed hosting beyond GitHub
Per-seat cost	$15/seat above included	Flat project pricing	Flat team pricing
Staging environment	$15/month extra dataset	Separate project deploy	Branch-based (free)
API rate limits	Generous on Growth	Your server limits	Git API limits
Enterprise	Custom (typically $1k+/month)	Custom	Not yet a clear path

Sanity's growth plan at $15/month per seat is the most common pain point I hear about. A five-person editorial team — three editors, one PM, one developer — sits at $45–60/month before you've counted bandwidth or asset storage overages. Add a staging dataset and you're at $75/month. That's not outrageous for a professional content operation, but it surprises teams coming from self-hosted WordPress.

Payload Cloud launched properly in 2024 and has matured. The Starter tier at $25/month gives you a managed MongoDB Atlas instance, file storage, and a hosted admin UI. It removes the ops burden without the per-seat cost structure. If your team is four developers with no non-technical editors, Payload Cloud is often cheaper than Sanity Growth.

Keystatic Cloud is the newest entrant. At $19/month for teams it's competitive, but Keystatic's architecture means it only makes sense for content that lives happily in a Git repo — flat Markdown or YAML files, reasonable document counts, no heavy asset management. For a developer blog or docs site it's excellent. For a marketing team managing hundreds of landing pages with hotspot images and scheduled publishing, it's the wrong tool regardless of price.

Self-hosted cost reality for Payload

Payload's self-hosted path deserves its own accounting. At minimum:

Compute: Railway Pro ($20/month), Render Starter ($7/month), or a $6 Hetzner VPS
Database: MongoDB Atlas free tier covers small projects; M10 cluster (production-appropriate) starts at ~$57/month
File storage: AWS S3 free tier for the first year, then ~$0.023/GB/month
Backups, monitoring: optional but real costs in any serious deployment

A realistic production Payload setup runs $30–100/month before you hire anyone to maintain it. That's still competitive with Sanity Growth for large teams, but it's not free infrastructure.

Total cost of ownership at three scales

Team size	Sanity	Payload (self-hosted)	Payload Cloud	Keystatic
Solo dev, personal project	$0	~$6–12/month	$25/month	$0
3-person startup (2 editors)	$0–15/month	~$30–60/month	$25/month	$0–19/month
8-person team (5 editors)	~$75/month	~$60–100/month	Custom	$19/month
20+ editors, multi-locale	$200+/month	$100–150/month infra	Custom	Not recommended

Which one to pick based on budget

Sanity wins on editor experience and GROQ flexibility. The cost is predictable once you've settled your seat count. For teams where non-technical editors are the majority of users, the per-seat model is worth it — the Studio quality keeps support tickets low.

Payload wins on total cost for developer-heavy teams or when you need full control of your data layer. Self-hosting has a real ops cost, but if you're already running infrastructure (many product teams are), adding Payload is marginal. Payload Cloud closes the ops gap at a flat rate.

Keystatic wins for content-in-Git workflows — docs sites, developer blogs, small marketing sites where a developer is close to the content. The pricing is lowest, the architecture is simplest, and branch-based staging is built in for free. It is the wrong choice when editors outnumber developers or when content is too large for a Git repo.

None of these is universally cheapest. The gap between them matters most at the 5–20 editor range, where Sanity's per-seat cost accumulates and Payload's self-hosting complexity starts to feel justified.

Sanity vs Webflow Pricing 2026: Real Costs Side by Side

Nayan Kyada — Tue, 29 Sep 2026 10:49:32 +0000

Sanity and Webflow both have "free" plans, but the cost curve diverges fast once you add editors, traffic, or a custom front end. This post puts the actual 2026 numbers side by side so you can see where each platform starts charging and what triggers the next tier.

What you're actually paying for on each platform

Sanity is a headless CMS: you pay for the API, the hosted Studio, and asset delivery. Webflow bundles CMS, hosting, CDN, and visual editor into one product. That bundling makes price comparisons awkward — with Sanity you always need a separate host (Vercel, Netlify, Railway), whereas Webflow's hosting is included.

To make this fair I'll break out the Sanity + Vercel cost as a single number where it matters, and I'll note when Webflow's bundled hosting is genuinely cheaper vs when it's padding the bill.

Free tier comparison

Feature	Sanity (Free)	Webflow (Starter)
Projects	Unlimited	2
Seats / editors	Up to 3	1 (owner only)
Documents	10,000 per project	50 CMS items
API requests	250,000 / month	N/A (no API access on free)
Asset bandwidth	10 GB CDN / month	Not published (Webflow hosting required)
Custom domain	Bring your own host	Paid plan required
API / webhooks	Yes, on free	Webhooks require Basic or above
Staging / preview	Draft mode, free	Staging link, free

Sanity's free tier is usable in production for small sites — you get real API access, webhooks, and three seats. Webflow's Starter is essentially a portfolio sandbox: 50 CMS items and no custom domain mean it doesn't survive contact with a real client project.

Paid plan pricing (September 2026)

Sanity

Plan	Monthly (billed annually)	Seats included	Documents	API calls	Asset bandwidth
Free	$0	3	10,000	250k	10 GB
Growth	$15 / seat	3 included	100,000	1M	100 GB
Team (volume)	~$50–80 / seat	Custom	Custom	Custom	Custom
Enterprise	Custom	Custom	Custom	Custom	Custom

Growth pricing is per seat above the three included. A five-person team pays $15 × 2 extra seats = $30/month on top of the $45 base, so $75/month total. Bandwidth overages on Growth are $0.10/GB.

Webflow

Plan	Monthly (billed annually)	Editors	CMS items	Bandwidth	E-commerce
Starter	$0	0	50	1 GB	No
Basic	$14	0	0 (static only)	50 GB	No
CMS	$23	3	2,000	200 GB	No
Business	$39	10	10,000	400 GB	No
Enterprise	Custom	Custom	Custom	Custom	Yes

Webflow workspace seats (for designers) are priced separately from site editors. A Workspace Freelancer plan is $24/month and covers one person across unlimited sites. Workspace Team is $42/seat/month. If you have a team of designers and editors, both meters run simultaneously — a common shock.

Where each platform gets expensive

Sanity cost cliffs:

Extra seats on Growth. At $15/seat, a ten-person content team costs $105/month in seat fees alone before bandwidth.
Asset bandwidth. Serving full-resolution Sanity CDN images without a transform pipeline burns the 10 GB free allowance in days on a mid-traffic blog. Use ?auto=format&w=800 query params and cache at the edge to stay inside the free tier longer.
Custom roles. Fine-grained document-level permissions (RBAC) require the Growth plan or above. If an agency needs to restrict editors to specific document types, that's a forcing function to paid.

Webflow cost cliffs:

CMS item cap. The 2,000-item CMS plan at $23/month caps out quickly for e-commerce catalogues or news archives. Moving to Business ($39) for 10,000 items is the first real jump.
Workspace seats for designers. The per-seat workspace billing is separate from per-site billing. An agency with four designers + one site = $168/month in workspace fees before even counting the site plan.
No headless API on lower tiers. Webflow's REST API and GraphQL access require at least the CMS site plan. If you want Next.js to fetch Webflow data, you're already at $23/month per site, and you still pay for a host.
E-commerce rates. Webflow takes a 2% transaction fee on the Standard e-commerce plan ($29/month). That disappears on Plus ($74) — a forced upgrade for any serious store.

Sanity + Vercel vs Webflow all-in

For a typical marketing site with 3 editors, moderate traffic (50k visits/month), and Next.js as the front end:

Scenario	Sanity + Vercel	Webflow (standalone)
CMS cost	$45/month (Growth, 3 seats)	$23/month (CMS plan)
Hosting	$20/month (Vercel Pro)	Included
Designer workspace	N/A	$24/month (Freelancer)
Total	$65/month	$47/month

Webflow wins on raw cost at this scale — but only if you don't need a custom front end. The moment you want Next.js handling rendering (RSC, ISR, PPR, custom components), you're fetching from Webflow's API anyway and still paying Vercel on top. At that point Webflow is just an expensive CMS with a visual editor you're no longer using for production layout.

When Sanity is cheaper

You have a custom Next.js front end and don't need Webflow's visual canvas.
Your content model is complex: nested references, localized fields, block-level components. Webflow's CMS is flat; Sanity's is not.
You need more than 10,000 CMS items. Sanity's Growth tier gives 100,000; Webflow Business tops out at 10,000 before enterprise.
You want GROQ-powered queries with join-level control over payload size. Webflow's API returns fixed shapes.

When Webflow is cheaper

Marketing teams want to own layout and CMS in one tool, with no engineering dependency for design changes.
The site is primarily landing pages with light CMS use (< 2,000 items).
Budget is tight and a separate host is an extra line item nobody wants to justify.
Visual editor parity matters — Webflow's Lottie/animation/CMS binding workflow has no Sanity equivalent out of the box.

The number that usually decides it

If the front end is already Next.js, Sanity almost always wins on total cost — the Webflow visual editor becomes sunk cost the moment a developer is rendering templates in RSC. If the site is entirely Webflow-rendered and the team is non-technical, Webflow's all-in pricing is genuinely simpler. The mistake is paying for Webflow's hosting and Vercel because nobody committed to a rendering strategy at the start of the project.