Headless CMS · New Zealand
A fast, editable site your marketing team actually owns.
A headless build splits the content from the front end: your team edits in Sanity, the site renders in Next.js, and the two talk over a content API. You get a fast, structured, ownable website instead of a WordPress theme held together with plugins — designed and coded by a senior engineer who does this for a living.
In short
What a headless CMS developer actually does
A headless CMS developer models your content as structured data in a CMS like Sanity, then builds a separate front end — usually Next.js and React — that pulls that content over an API and renders it. “Headless” just means the content store has no fixed front end bolted on: instead of WordPress owning both your database and your theme, Sanity owns the content and your site owns the presentation. That split is what makes a composable build fast, flexible and portable — the same structured content can feed a website, a mobile app, an email system or an in-store screen, and you can rebuild the front end without ever touching the content. For a New Zealand marketing team or agency, it’s the difference between fighting a page-builder and having a site that’s genuinely quick to edit and genuinely yours.
What we build
What a headless build includes
Most projects are a Sanity content model wired to a Next.js front end, plus whatever the site actually needs. If it involves structured content, editing and a fast public site, it’s in scope.
Content model & Sanity Studio
A schema designed around your content, not a page-builder — defineType and defineField, reusable objects, references instead of duplicated data, and a Studio your editors log into that’s customised to how your team actually works.
Next.js front end
The public site, hand-coded in Next.js and React with the App Router: content fetched in server components over GROQ, TypeScript types generated from your schema, and on-demand revalidation so an edit goes live in seconds without a full rebuild.
Portable Text & rich content
Body content stored as Portable Text — structured blocks, not a soup of HTML — rendered with custom serializers so a callout, a code sample or an embedded product renders as a real component instead of pasted markup.
Visual editing & live preview
Sanity’s Presentation tool wired up so editors click an element on the live site and jump straight to the field, with draft previews of unpublished changes. Editing stays close to what the reader sees, without a fragile page-builder.
Migration off WordPress or a monolith
Existing content mapped into a clean schema and moved across — HTML converted to Portable Text, images pulled into Sanity’s asset pipeline, and old URLs redirected so you don’t lose the rankings you already have.
Images, search & performance
Sanity’s image CDN with on-the-fly cropping and format conversion, GROQ-powered search and filtering, and a front end that ships as static-fast pages — the speed and Core Web Vitals a plugin-heavy WordPress site struggles to hit.
In depth
How to think about a headless build
What “headless” and “composable” actually mean
A traditional CMS like WordPress is coupled: the same system stores your content and renders your pages, and your theme, plugins and content are tangled together. Headless decouples them — the CMS becomes a content API, and the front end is a separate application you build however you like. Composable takes that further: content, search, commerce, analytics and hosting are each a focused service you choose and wire together, rather than one monolith trying to do everything. The practical payoff is real. The front end can be a fast Next.js app instead of a theme; content is structured data you can query and reuse anywhere; and when you want to redesign in three years you rebuild the presentation without migrating the content again. The cost is that someone has to build and connect those pieces — which is exactly the work this page is about.
Why Sanity, and where another headless CMS fits
Sanity is my default for most builds because it treats content as real structured data rather than pages. You define the schema in code (defineType, defineField), query it with GROQ, and store rich text as Portable Text — so a “body” field is an array of typed blocks you can render as proper components, not a locked HTML blob. The Studio is a React app you customise and self-host, and the Presentation tool gives editors click-to-edit visual editing on the live site, which is usually the thing that wins a marketing team over. It’s not the only good option — Contentful, Storyblok, Payload and others each have a place, and if you’re already invested in one I’ll build against it rather than force a switch. But when the goal is a content model that stays clean as it grows, an editing experience people don’t fight, and a codebase you own end to end, Sanity is what I reach for first.
When you don’t need headless — and a simpler option is right
Headless is not automatically the better choice, and I’ll say so before you spend on one. If you have a small brochure site of a few pages that barely changes, a well-supported platform like Squarespace or a tidy WordPress install is cheaper, faster to stand up, and needs no developer to keep running — go with that. If your team wants to drag blocks around and build whole pages themselves with zero developer involvement, a page-builder genuinely serves that better than a structured model does; headless trades some of that freeform layout control for consistency and speed. And if nobody on your side will ever touch the content and it truly never updates, a static site or even a single-file build is the honest answer. Headless earns its keep when content changes often, when the same content needs to appear in more than one place, when performance and SEO actually move the needle for you, or when you’re tired of a plugin stack breaking every time something updates. If that’s not you, I’ll point you at the simpler thing.
Migrating off WordPress without losing your rankings
Most headless projects start as a migration, and the fear is always the same — losing the search rankings you’ve built. Done properly, you don’t. The work is: model your existing content types as a clean Sanity schema, export the old content (WordPress has a REST API and an export file), convert each post’s HTML body into Portable Text so it becomes structured blocks rather than pasted markup, pull the media into Sanity’s asset pipeline, and — the part that protects your SEO — map every old URL to its new one with proper 301 redirects so link equity carries over. A rebuilt front end that’s faster and cleaner than the WordPress original tends to help rankings rather than hurt them, provided the redirects, metadata and structured data are handled with care. I do that migration as part of the build, not as an afterthought you discover is missing.
Who you actually work with
Not an account manager fronting an offshore team — Isaac Vicliph, a senior software engineer with a decade shipping software in financial services, doing the content modelling and writing the code himself. You get one accountable person from the first scoping call to launch, direct contact throughout, and a schema and front end designed by the person who’ll build them. It’s a deliberately small operation focused on Sanity and Next.js work: fewer projects, no junior hand-off, and the person who understands your content model is the person who wrote it. NZ-based, priced in NZD, GST-registered.
How a project runs, and how it’s priced
I scope before I quote. The first step is a conversation about the actual site — how much content there is, how often it changes, who edits it, what needs to migrate — followed by a written plan: the content model, the front end, the migration, what you own at the end, and a fixed price for that scope. No hourly meter, no open-ended estimate that drifts. A focused marketing site is a smaller job than a large multi-language build with a heavy migration, so rather than publish a number that’s wrong for your project, I give you a firm one once I understand it. Tell me what you’re running now and what you want instead, and you’ll get a straight plan and a straight price back.
Reviewed July 2026 · written by Isaac Vicliph, Tally Digital
Questions
Frequently asked
What is a headless CMS?
A CMS that stores your content as structured data and serves it over an API, with no fixed front end attached. Instead of WordPress owning both your content and your theme, a headless CMS like Sanity owns the content while a separate application — usually a Next.js site — owns how it looks. That split makes the site faster, the content reusable across web, app and other channels, and the whole thing portable.
Why Sanity instead of WordPress, Contentful or Strapi?
Sanity treats content as structured data you define in code and query with GROQ, stores rich text as Portable Text you can render as real components, and gives editors click-to-edit visual editing on the live site through its Presentation tool. WordPress couples content to a theme and leans on plugins; Contentful, Storyblok and Payload are all reasonable headless options too. If you already run one of them I’ll build against it rather than force a switch — but for a clean, ownable, fast build, Sanity is my default.
How much does a headless CMS build cost in New Zealand?
It depends entirely on scope — a focused marketing site is a very different job from a large multi-language build with a heavy WordPress migration, so a blanket price would be misleading. I scope your actual content and site first, then give you a fixed price for that scope before any work starts: no hourly meter and no open-ended estimate. Tell me what you’re running now and what you want, and you’ll get a firm number back.
Can you migrate our WordPress site to Sanity without losing SEO?
Yes — migrations are most of what a headless project involves. I model your content as a clean schema, export the existing content, convert HTML bodies into Portable Text, move the media into Sanity’s asset pipeline, and — the part that protects your rankings — map every old URL to its new one with proper 301 redirects. A faster, cleaner front end usually helps search performance rather than hurting it, provided redirects, metadata and structured data are handled carefully.
Can our marketing team edit the site without a developer?
Yes — that’s the point. Editors work in Sanity Studio, and with the Presentation tool set up they can click an element on the live site and jump straight to the field that controls it, with previews of unpublished drafts. Day-to-day content, images and copy are all yours to change without touching code or waiting on me. Structural changes — new content types or new page templates — are development work, but everyday editing is not.
Do we own the site and the content?
Yes, outright. You own the Next.js repository, the Sanity project and dataset, and the hosting accounts. Your content isn’t locked in — Sanity content exports as a portable file (NDJSON plus assets), and the front end is a mainstream Next.js and TypeScript codebase any competent developer can pick up. The whole reason to go headless is that both your content and your code are assets on your side of the table.
Is headless right for a small brochure site?
Often not, and I’ll tell you honestly. For a few pages that rarely change, a platform like Squarespace or a tidy WordPress install is cheaper and needs no developer to maintain. Headless earns its place when content changes often, when the same content feeds more than one channel, when speed and SEO genuinely matter to you, or when a plugin stack keeps breaking. If a simpler option fits, I’ll point you at it rather than sell you a build.
Are you a developer or a digital agency?
A senior software engineer. Headless CMS builds, Sanity content modelling, Next.js front ends and migrations — not templates, not a monthly marketing retainer. You talk to the person who designs the schema and writes the code, every time.
Tell me what you’re editing your site in now.
The WordPress install fighting its plugins, the page-builder your team dreads, the site that’s slow and hard to change — tell me what you’re running and I’ll scope a Sanity and Next.js build that’s fast, easy to edit and yours to own, then come back with a clear plan and a fixed price.