Sanity vs Payload: Why Payload Became My Default

Sanity is excellent at one thing most clients don't need, and charges by the person to do it. Here's the line I draw now.

I've shipped production sites on both, and I'd still reach for either one. But my default changed, and it changed for a reason worth writing down.

Payload is what I build on now unless a project gives me a specific reason not to. Sanity is what I reach for when it does.

There's essentially one reason, and it's not a feature comparison.

What changed my default

The framing that took me a minute to get: Payload doesn't sit next to your Next.js app and talk to it over an API. It runs inside your app. Same repo, same next build, same deploy. The admin panel is a route in your application.

The consequence is that the network hop disappears. In a server component you query the database directly:

// Payload — local API, no network request, types generated from your schema
const payload = await getPayload({ config })
const { docs } = await payload.find({
  collection: 'posts',
  where: { status: { equals: 'published' } },
  limit: 10,
})

// Sanity — a query language, over the network, to someone else's servers
const posts = await client.fetch(
  `*[_type == "post" && status == "published"][0...10]`
)

Neither of these is bad code. But the first has no round trip, no CDN cache to reason about, no metered request, and no separate schema to keep in sync — change a field and TypeScript tells you what broke before you reload the page.

What I've gotten the most mileage out of:

• The form builder. Build forms in the admin UI, get submissions stored, get email notifications wired. For a small business site that's most of the "dynamic" functionality anyone actually asked for, and it's a plugin instead of a project.
• Access control as functions. Permissions are code — a function that takes the user and returns a boolean or a query constraint. Arbitrary logic, versioned in git, reviewed in a pull request.
• The admin UI is generated from config. Define the collection, get the interface. Override any piece of it with your own React components when a client needs something specific. I haven't had to fight the framework to do it.
• One system instead of two. When a project needs a portal, a calculator, an integration — anything with a database behind it that isn't content — the backend already exists. Adding a collection beats standing up a second service next to your CMS.
• No per-seat cost, because nobody's counting seats. MIT licensed, self-hosted. Twenty editors cost exactly what two do.

That last point is the one that moved the default.

The pricing pattern

Sanity's cost scales with the size of your team, not the size of your site. A brochure site with twelve editors costs more than a 500-page site with two.

The free plan includes a generous 20 seats, which sounds like it settles the question — until the next line. The free plan ships two roles: Administrator and Viewer. Full access, or read-only. Nothing in between.

So the moment you want the thing Sanity is actually good at — a contributor who drafts but can't publish, an editor who can't touch the schema — you're on the Growth plan at $15 per seat, per month. Every person who logs in. A ten-person team runs $1,800 a year before a single overage, and there are overages: API requests, CDN requests, bandwidth, and assets are all metered past the included quota.

The trap isn't the price. It's what the price is for. You're buying real-time collaboration and a permission hierarchy. If a client's content team is one office manager who updates the hours page twice a year, that's a subscription indexed to a team that doesn't exist — and it's the client who pays it, every month, forever, whether or not anyone logs in.

I've stopped recommending that. For most of the sites I build, it's a recurring cost with nothing on the other side of it.

The case where Sanity clearly wins

I want to be precise here, because "Sanity is expensive" is a lazy conclusion and I don't believe it.

The largest build I've done on it is the rebuild of the agency site where I work — 150+ pages, a marketing team, writers, a designer, and me. That's the shape where the per-seat cost starts paying for itself.

What earns it:

• Roles that match how the team is actually structured. A contributor drafts. An editor publishes. A developer touches the schema. Nobody holds more access than their job needs — which is the entire reason a marketing site doesn't get broken by the person who was only trying to fix a typo.
• Real-time, multiplayer editing. Actual presence, actual concurrent edits. Two people in one document is a Tuesday, not an incident.
• Live preview a non-technical person will actually use. Click text in the preview, land on the field that produces it. That one feature ended more Slack threads than anything else I built.
• Content releases. Stage a batch of changes and publish them together, which is how marketing teams already think — campaigns, not commits.

Note what the trigger actually is. It isn't "two people typing at the same instant" — that's the demo, and it's rarer than the demo implies. It's role separation and a publishing rhythm: enough people that they need to be told apart, editing often enough that a review step is real. A team where a writer drafts on Monday and an editor approves on Wednesday never collides once, and still gets its money's worth.

If that's your team, pay for Sanity. Payload's drafts, versions, and live preview are good, and they are not the same thing — Sanity has years of maturity on collaboration that Payload hasn't had time to accumulate. Don't make a content team fight the wrong tool to save a line item.

I'll go further than a fair-and-balanced note here: Sanity's editing experience is the best I've used, and on Payload builds I notice what's missing. What I don't miss is explaining to a two-person business why their website carries a subscription that grows when they hire someone.

Including where I got it wrong

I'll hold my own build to the same standard. I'm no longer certain I'd make the same call today.

"The team is big, so use Sanity" is the lazy version of this reasoning, and I've caught myself using it. Headcount isn't the criterion — overlap is. The question was never how many people have logins. It's how many of them need to be in the same document, on the same afternoon, holding different permissions. That number is usually smaller than the org chart implies, and I picked the tool before I'd honestly measured it.

I don't regret the architecture. Getting non-technical editors out of the front end was the point of the whole migration, and it worked. But that's an argument for headless, not an argument for a specific CMS, and I let the first conclusion carry the second. If I ran the numbers now and the real overlap turned out to be two people, the honest answer would be that a chunk of that subscription is buying a problem we don't have.

That's the exception. In my work it's been about one project in ten — and I'm less sure than I was that my own project is in the ten.

What Payload asks of you instead

Self-hosted means you host it. That's not a footnote.

You own the database, the backups, the upgrade path, the file storage bucket, and the 11pm phone call. Managed hosting was Payload Cloud's job, and after Payload was acquired by Figma in 2025, new Cloud signups were paused. Existing customers continued; new projects run somewhere else. In practice that means Vercel plus a managed Postgres or Mongo provider, and it lands most production sites around $25–60/month in infrastructure.

Cheaper than a ten-seat Sanity plan. Not free, and not zero-maintenance.

The honest version of the pitch is that Payload doesn't remove the cost — it moves it from a subscription to an operator. That works when the client has one, which is why it pairs naturally with a maintenance arrangement. It works less well for a client who wants a vendor with an SLA and a support contract to point at. Some clients genuinely want that, and it's a fair thing to want.

The acquisition deserves its own sentence, because clients ask. The repository is still MIT licensed and still open source, which is the part that matters — the code you shipped can't be taken away from you. But betting a client's site on a roadmap now owned by a design company is a real consideration, and I'd rather say it out loud than pretend the risk is zero.

The decision, in one question

Asked in discovery, before any of the above comes up:

How many people are going to log in, and do they need to be told apart?

Three or more with distinct roles, publishing on a regular schedule — that's Sanity. The per-seat cost buys something the team uses every week.

Anyone else — and that's most small businesses — is Payload. A typed backend, a form builder, an admin panel, and the site itself in one repo, with no invoice that grows when you hire someone.

The tie-breaker, when it's genuinely close: does the project need custom application logic behind a database that isn't content? Payload, every time. You already have the backend.

Neither of these is a downgrade from WordPress, and Sanity isn't a downgrade from Payload. They answer different questions. It's just that the question Sanity answers — how do we keep a team of people from stepping on each other? — is one most small businesses never have to ask, and it's the expensive one to answer by default.

If you want the version that starts a step earlier, I wrote about what headless CMS actually means for a small business. And if you're weighing this for a real project, let's talk it through — the answer depends on who's logging in, and that's a five-minute conversation.