Best Headless CMS for Agencies: Sanity vs Payload vs Storyblok
DEV Community

Best Headless CMS for Agencies: Sanity vs Payload vs Storyblok

Most comparisons of the best headless CMS for agencies score developer experience and stop there. Agencies live or die on other things: how cleanly a project hands over, how long editor training takes, whose name is on the invoice, and whether the monthly margin survives client number fifteen.

This post compares Sanity, Payload and Storyblok on those operational questions. For the developer-side view, see my general headless CMS comparison for Next.js.

The short version

If you want the answer before the reasoning: Sanity is my default when the client will own the account and wants a tailored editing experience. Payload wins when you want to control hosting and avoid per-seat pricing across many small sites. Storyblok wins when the buyer is a marketing team that wants to click on the page and edit in place, and the agency is happy to train around its component model.

Agency concern Sanity Payload Storyblok
Hosting Managed content backend, Studio deployed by you or Sanity You host app and database Managed
Licensing model Per-project plans, seat-based on paid tiers Open source, no CMS license fee Per-space plans, seat-based
Client owns billing Easy, project belongs to client org Client owns infra if you set it up that way Easy, space belongs to client account
Editor training effort Low to medium, depends on Studio design Medium, admin panel is generic unless customised Low for visual editing, medium for component setup
Handover risk Low Medium, you hand over infrastructure Low
Ongoing margin lever Maintenance retainer Hosting plus maintenance Maintenance retainer

Prices change often. Check each vendor's pricing page before quoting a client; I cover current numbers in my posts on Sanity pricing, Storyblok pricing and Payload pricing.

Client handover

Handover is where agency margin quietly leaks. A project that takes a week to untangle at the end is a week of unpaid work.

Sanity. The content lives in a Sanity project that belongs to an organisation. Create the project under the client's organisation, invite your team as admins, and handover is mostly a permissions change plus documentation. The Studio is a React app, so you also hand over a repository and a deploy target. Tokens, CORS origins and webhooks are the things people forget; my handover checklist lists them.

Payload. You are handing over an application, not just a CMS account. That means a hosting account, a database, file storage, environment variables, backups and an upgrade path. This is powerful, since the client truly owns everything, but it is also the heaviest handover of the three. If the client has no technical person, you either keep running it (and carry the risk) or you teach them to.

Storyblok. Content and the visual editor live in a space under the client's account. Handover is the lightest: transfer or share the space, document the component library, and hand over the frontend repository. The trap is that the component definitions in Storyblok and the React components in your frontend must stay in step, so a future developer needs to understand both.

Editor training

Training time is a cost, and it also decides whether the client is happy six months later.

  • Storyblok has the shortest path for people who think in pages. Editors click a block on a live preview and change it. The cost shows up later, when they want a layout the components do not allow.
  • Sanity is as easy or as hard as you make it. A Studio with five document types, sensible field groups, validation and live preview is learnable in an hour. A Studio with forty types and raw reference fields is not. Structure design is the real work, and I wrote about it in why editors avoid the Studio and what to set up before editors touch it.
  • Payload gives you a clean admin panel out of the box and strong access control, but without customisation it feels like a database editor to a marketer. Live preview exists, and good layout-builder fields help, yet expect to invest more design time per project.

If your clients are non-technical and turnover on their side is high, favour whichever tool lets you write the shortest training document.

Licensing per client

This is where the three differ structurally. Sanity and Storyblok both bill per project or space, and paid tiers add seat costs. The useful agency question is who the billing entity is. If every client has their own organisation and card on file, your costs for that client are zero and the CMS cost is a pass-through line the client sees directly. If you hold the account, you become a reseller and take on payment risk.

Payload has no per-seat or per-project license fee. What you pay for is the infrastructure underneath. One shared database and app deployment per client is the cleanest isolation. Multi-tenant setups on one deployment are cheaper but couple your clients' uptime and upgrade schedule together, which I would only do for sites you fully own.

A simple rule: if a client's content backend can be switched off by your payment failing, you have built a liability, not a service.

Margin

Margin comes from three places: build, ongoing work, and recurring pass-through.

  • Build. Storyblok is typically fastest to a first demo for page-builder style sites. Sanity is fast once you have your own starter schema. Payload is fast for developers who already have a template, but slower when clients need custom editing UX.
  • Ongoing work. Managed backends (Sanity, Storyblok) let you sell a maintenance retainer that covers dependency updates, small changes and monitoring. With Payload you can add hosting, backups and security patching to the retainer, which is more revenue but also more responsibility.
  • Pass-through. Do not mark up SaaS CMS seats silently. Clients find out, and it costs more trust than it earns. Mark up your time instead.

The practical agency pattern is a reusable starter. For Sanity, that means a shared schema package, a content model for pages, posts and settings, a webhook route for revalidation, and a typed query layer. Something like this lives in every project:

// sanity/schemaTypes/index.ts
import { pageType } from './pageType'
import { postType } from './postType'
import { settingsType } from './settingsType'

export const schemaTypes = [pageType, postType, settingsType]

The less each new client requires you to invent, the better the margin, whichever CMS you pick.

Where each one breaks for agencies

  • Sanity: an over-flexible Studio. Agencies that give every client a bespoke schema end up maintaining fifteen content models. Standardise.
  • Payload: operations. A security patch or a Next.js major upgrade across many self-hosted clients is real work, and somebody has to be on call.
  • Storyblok: component drift and seat-based growth. When a client adds editors, costs scale, and large redesigns mean reworking components in two places.

What I would pick by agency type

Design-led agency selling to marketing teams: Storyblok, or Sanity with Presentation live preview.

Dev-heavy agency with many small sites and strong ops: Payload.

Agency that wants clients to own everything and wants a distinctive editing experience: Sanity.

If you want a second pair of hands on a client project, I take on this kind of work through my white label arrangement for agencies. Sanity + Next.js builds start from $4,000, with details at /services#packages. For a direct two-way view, see Storyblok vs Sanity for Next.js and Payload vs Sanity.

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.