Choosing a Headless CMS for Your SaaS Marketing Site in 2026

Almost every headless CMS comparison you'll read was published by a company that sells a headless CMS. That isn't a conspiracy, it's just where the content budget sits. Vendor blogs out-publish independent engineers by a wide margin, so the roundup you land on usually ends with the host's own product winning on points. I've shipped marketing sites three different ways: content committed as markdown in the repo, content living in Postgres tables the client owns, and content behind a hosted API with a seat bill attached. The feature grid decided none of them.

What decided them was who edits the content, how often, and what happens the day that person needs a page shape your model didn't anticipate. This post walks the four options I'd actually consider for a SaaS marketing site, and the specific failure each one has.

What Does a Headless CMS Actually Buy a SaaS Marketing Site?

It buys you content outside your codebase, so a marketer can publish a page without a developer, a pull request, or a deploy queue. Everything else in the sales deck is downstream of that one capability. A headless CMS keeps the content store and the rendering layer separate and serves content over an API, which means your Next.js frontend stays yours and the editing surface stays theirs.

The corollary matters more than the promise. If nobody on your team is going to edit content without a developer anyway, you're paying a subscription and a maintenance tax for a workflow you don't use. A two-person startup where the founder writes the copy and the engineer commits it does not need Contentful. It needs a folder.

Contentful vs Sanity: The Pricing Model Decides More Than the Feature List

The two market leaders bill on structurally different axes, and that difference will dominate your five-year cost more than any capability either one ships. Contentful's pricing page lists Lite at a flat $300/month covering 20 users, 3 roles, and 3 locales. Sanity's pricing page lists Growth at $15 per seat per month for up to 50 seats, with a free tier that already covers 20 seats.

| | Contentful Lite | Sanity Growth | |---|---|---| | List price (2026) | $300/month flat | $15 per seat/month | | Users included | 20 | up to 50 seats | | Roles | 3 | 5 | | Locales | 3 | Unlimited | | Free tier ceiling | 10 users, 2 locales, 25 content types, 100K API calls | 20 seats, 250k API requests, 1M CDN requests | | Overage model | Upgrade the plan | $1 per 250k CDN requests, $0.30 per GB bandwidth |

Read the crossover point off that table. A four-person marketing team pays $60/month on Sanity and $300 on Contentful for the same work. At thirty editors the gap narrows and the flat rate starts looking rational instead of punitive. Most SaaS companies below Series B never get to thirty editors.

The locale row is the one people discover late. Three locales on Contentful Lite sounds generous until sales wants German, French, Spanish, and Dutch in the same quarter, and the answer is a jump to Enterprise with custom pricing and a procurement cycle attached. If you already know you're going multi-language, that row is your decision, and editor UX is a tiebreaker.

Payload Is a Different Kind of Bet Now

Payload runs inside your Next.js app instead of behind someone else's API, which moves the risk from vendor pricing onto your own hosting and maintenance. Payload 3 installs directly into the App Router, so the admin panel and the marketing site are one repo and one build. A single schema definition gives you REST and GraphQL endpoints plus a local API you can call server-side without a network hop. For a Next.js team that already owns a Postgres instance, that's the cleanest architecture on this list.

Then Figma bought them. The acquisition was announced on June 17, 2025, with Figma saying Payload stays open source and that nothing changes for users in the immediate future. Both halves have held up so far — the release notes show v3.85.2 shipping on July 7, 2026, a security patch more than a year after the deal, which is what a still-maintained project looks like.

What did change is hosting. Payload Cloud stopped taking new signups, so a greenfield Payload project in 2026 means deploying it yourself on Vercel, or on a VPS you patch. Actually, let me be more precise about the risk. The concern isn't abandonment, it's steering. Figma is building a CMS for Figma Sites and Payload is the backend they bought to do it, so the roadmap now answers to a design tool's priorities rather than a B2B marketing team's.

Sometimes the Right CMS Is a Folder

You've felt this one. The client swore they'd update the site themselves, and eighteen months later every change has still come through you.

Outstatic is the middle path for that reality: a dashboard that writes Markdown and MDX straight into your GitHub repo, with no database and no server behind it. Content is versioned in git, reviewable in a pull request, and shipped through the pipeline you already have. The editor gets a real writing surface. You get diffs.

The failure mode is honest and easy to predict. No scheduled publishing, no granular roles, no per-field validation, and every publish triggers a full deploy. If your marketing lead publishes twice a week, fine. If they publish six times a day and need a launch scheduled for 9am Tuesday, it isn't.

On the Pizzeria Bestek build I skipped the CMS layer entirely for a related reason. Four languages, a React and Supabase stack, and an owner who runs a kitchen. Copy lives in translation files, menu data lives in Supabase, and the whole admin workflow is a CONFIRM or DECLINE button inside an email. He has never logged into a dashboard, because a dashboard was the thing he was trying to escape.

Does Your Content Model Survive Programmatic SEO?

Only if you model reusable content types before you evaluate vendors, because comparison pages and glossary terms are separate types that share one rendering contract. The tell for a bad model: you find yourself adding a richTextBlock field to hold whatever the last page needed. Once that field exists, every future page uses it, and your content is unstructured prose again.

The Build Step Nobody's Pricing Page Warns You About

Static generation at scale can trip your CMS rate limit, because Next.js runs getStaticProps and getStaticPaths in parallel and fires simultaneous API calls during the build. Developers in a long-running Next.js discussion thread report 429 responses mid-build once the page count climbs. The site works fine in development and dies at deploy time, which is a genuinely miserable class of bug to debug at 11pm before a launch.

The fixes, roughly in the order I'd try them:

1. Cache at build time. Deduplicate identical queries across the build so one fetch serves every page that needs it. Cheapest fix, biggest win, no config trade-off.
2. Reduce build parallelism. Setting workerThreads: false and cpus: 1 in next.config.js serializes the build. It works, and it makes your builds slower — take that trade only if caching wasn't enough.
3. Retry with backoff. Detect a 429, read the retry header, wait, try again. Turns a hard build failure into a slow build.
4. Fetch once, then map. Pull the whole content set in one query and resolve each page from memory instead of querying per page.

Check the quota row against your page count before you sign anything. Sanity's baseline of 250k API requests plus 1M CDN requests per month sounds enormous until a CI pipeline rebuilds two thousand pages on every merge to main.

How Do You Actually Choose?

Pick the constraint that will bite you first, then choose the tool that doesn't have it: editors, locales, hosting, or page count. In practice that resolves to a short procedure.

1. Count the humans who will edit content without a developer in the next twelve months. Zero means markdown in the repo, and you can stop here.
2. Count your locales. More than three rules out Contentful Lite.
3. Check whether you own a database and a deployment you're willing to maintain. Yes points at Payload, no points at a hosted API.
4. Estimate your page count at 24 months, then compare it against the API quota on the plan you'd actually buy.
5. Only now open the editor UX, and open it with the person who'll use it daily sitting next to you.

Step 1 is the same modeling discipline that drives a SaaS MVP stack decision, and it's the step teams skip. I go deeper on the tool-by-tool tradeoffs in my breakdown of the best CMS options for marketing sites, and if you're weighing a headless setup against a visual builder instead, the Contentful vs Webflow comparison covers that fork directly.

Worth saying plainly: none of these will fail you outright. Contentful, Sanity, Payload, and a git-backed markdown workflow all ship real marketing sites today. The bad outcome comes from choosing on the feature grid, then discovering in month eight that the constraint you never checked is the one governing your roadmap.

So before you open another comparison table: how many people will touch your marketing content next quarter, and which of them has ever opened a pull request?