Why choose Sanity and Next.js: the case for going headless

Most arguments for going headless are aesthetic. Here are four mechanical ones, each of which shows up as either money or risk on a real project — and a counterweight section, because the honest case includes where this stack loses.

The neutral numbers are in the three-year cost comparison; the opposite argument is in the case for Umbraco.

One document holds every language

This is the difference that compounds. In a traditional CMS, localisation usually means a per-culture node or a parallel document per language. In Sanity each translatable field is an array whose members carry their own language tag, so one document holds every locale.

{
  "_type": "insight",
  "title": [
    { "_key": "a1b2c3d4", "language": "en", "value": "Why choose Sanity" },
    { "_key": "e5f6a7b8", "language": "ar", "value": "لماذا تختار Sanity" }
  ]
}

The front end resolves the active locale in the query, with a fallback, so a missing translation degrades to English instead of a blank page:

*[_type == "insight" && slug.current == $pathname][0]{
  "title": coalesce(
    title[language == $locale][0].value,
    title[language == "en"][0].value
  )
}

Three consequences that matter commercially:

1. Adding a locale is configuration, not migration. One line defines the locale; every existing document can now hold it. In a per-node model, a new language is a new content tree.
2. Languages cannot structurally drift. Editors see both versions of a field side by side on one document, so the Arabic page cannot quietly lose a section the English one gained.
3. The storage cost stays bounded. Because localisation lives inside fields defined by the schema, the attribute count does not grow with the number of locales.

And the translation itself is metered, not quoted

Sanity's editor assistant understands those localised fields and translates them in place. Priced against professional Modern Standard Arabic at $0.10 to $0.15 a word, a 150-document bilingual pass is roughly 60,000 words — about $7,200 of human translation against roughly $40 of AI credits. A four-locale estate of 450 documents is $54,000 to $81,000 against about $760.

Be honest about what that is, though: machine translation with human review is not the same product as human translation, and for some Gulf brands it is not an acceptable substitute. Treat it as a first pass that a reviewer edits — our multilingual SEO guide covers what bilingual quality actually demands, and the RTL engineering guide covers the front end.

Editors click the real website to edit it

The standard objection to headless is that editors lose preview. With visual editing wired up, the opposite happens: they get something a traditional CMS structurally cannot offer.

Because content values carry invisible metadata identifying the document and field they came from, an editor on the live Next.js site can click any piece of text and land on that exact field. Not a preview of the CMS's own templates — the real production front end, with the real design, the real fonts and the real responsive behaviour.

A traditional CMS previews the templates it renders. That is excellent when it also renders your site, and worthless the moment a separate front end does — at which point click-to-edit against an external app is eight to fifteen developer days to build yourself, if you build it at all.

Nobody on your team patches a CMS

Count the surfaces you are responsible for. Self-hosting a traditional CMS gives you four — the operating system or PaaS, the language runtime, the CMS itself, and its add-ons — plus a database to operate and back up.

With Sanity there is no CMS server. The vendor patches the content backend because you never deploy one. That leaves npm dependencies as your only patch surface, which is real work but is one surface rather than four.

One symmetry worth stating, because it cuts against the marketing on both sides: no host patches your framework. Vercel's own guidance on Next.js advisories is that patching is the only complete mitigation, and it does not deploy WAF rules on your behalf for them. Managed hosting moves the infrastructure burden, not the maintenance one. What it genuinely removes is the CMS and database burden — and at a small site's scale, that labour costs more than the entire hosting saving from self-hosting.

The content model is the API

Schemas are TypeScript. Queries are typed against the deployed schema, so the shape a component receives is generated rather than assumed, and a field rename surfaces as a compile error instead of an empty div in production.

In practice that changes the pace of ordinary work. Adding a new section type to a page builder is a schema file, a registry entry, a React component and a regenerated type — and every consumer of the old shape fails loudly at build time if you got it wrong. Any React developer is productive in it without CMS-specific certification, which is its own hiring argument: in the UK contract market there were roughly 177 Next.js advertisements against 2 for Umbraco.

Performance and answer-engine readiness come with the framework

Incremental regeneration, streaming, the metadata API and image optimisation are framework features rather than plugins. Structured data, a dynamic sitemap, per-type metadata and machine-readable content summaries for AI answer engines are code you write once and apply to every document type — see how headless changes SEO and optimising for answer engines.

You can take the content with you

Portability is worth checking before you are ever motivated to use it.

npx sanity dataset export production ./backup.tar.gz

That yields newline-delimited JSON plus the asset binaries. Rich text is Portable Text — an open, documented specification with conversion libraries for HTML, Markdown and every major framework — rather than a proprietary blob or vendor-specific markup. There is also no published end-of-life on the Studio, so old majors keep working and nothing forces a migration on a vendor's timetable.

The honest caveat: a real replatform still means converting Portable Text and remapping your schema, which is bespoke work exactly as it would be leaving any CMS. The difference is the format you start from, not the absence of effort. Note also the asymmetry with self-hosting a traditional CMS — there you own the database outright, which is stronger custody even though it is a less portable shape.

Where this stack costs you, honestly

1. No form builder. Every form is a developer task and a deploy. Our own contact form is a block, an API route, reCAPTCHA verification, a Slack webhook, Redis rate limiting, a honeypot and a same-origin check — and adding a field still needs a developer. A traditional CMS hands that to editors for free or for about $130 a year.
2. Every editor affordance is a build decision. Content hierarchy, roles beyond the basics, slug rules, publishing guards — all designed rather than shipped. Reaching parity with a traditional backoffice is several hundred lines of Studio configuration before you write a single page.
3. Seats are priced. $15 per occupied seat per month, viewers free. Twenty editors is $300 a month against €0 on Umbraco Cloud.
4. The upper limits are cliffs, not slopes. Documents hard-cap at 25,000 on Growth, a third dataset is $999 a month, seats cap at 50, and an uptime SLA, custom roles, full audit trail, backups and content releases are enterprise-only and unpurchasable on Growth. Nothing costs more until something is simply unavailable, and then the only door is an unpriced enterprise contract.
5. No published data residency. If a contract requires content to sit in the UAE or on-premises, this stack cannot comply at any price, and Vercel has no Middle East region among its priced regions. That is the one requirement that ends the conversation.

Two configuration traps worth knowing early

• Uncached reads cost ten times cached ones — $1 per 25,000 API requests against $1 per 250,000 CDN requests. A front end that bypasses the CDN for content freshness pays the higher rate on every read. Decide that deliberately.
• Free datasets are public. Anyone who learns the project ID reads everything, including unpublished drafts. Private datasets are a paid-plan capability, so Growth is the real floor for client work — not a step up from free.

So when is headless the right answer?

1. Genuinely bilingual or multilingual content where the languages must stay structurally in step. This is the strongest case and it is why our own site is built this way.
2. Click-to-edit preview of the real front end is part of what you are promising editors.
3. Performance, SEO and answer-engine visibility are the product, not a later optimisation.
4. Nobody on the team wants to own a server, a runtime and a database — and the maintenance labour rate is high enough that ops time costs more than managed hosting.
5. You want predictable, cancellable spend with no annual escalator, and no dated deadline at which an un-upgraded site stops working.

And the inverse, stated plainly: if there is a residency clause, a .NET mandate, a large editorial team on a tight budget, or editors who must build their own forms, choose the traditional CMS. We build both for exactly that reason.

We do WordPress to Sanity migrations and headless web development in Dubai. If you are mid-decision, the three-year cost comparison has the numbers with their sources, and migrating without losing rankings is the checklist we run so a replatform does not cost you traffic.