Choosing a Headless CMS for Your SaaS Marketing Site in 2026

Before you compare a single headless CMS for your SaaS marketing site, count the people who will edit content without a developer next quarter. If the answer is zero, put Markdown files in your repo and stop reading comparison posts. If it's one or more, the next step is to check how each vendor bills, because the billing axis and your own numbers decide this more often than the feature grid does.

Most roundups you find on this topic are written by companies that sell a CMS, so read them with that in mind. This post uses only what the vendors publish on their own pricing and documentation pages, checked on 30 September 2026, and it says plainly where I could not verify a number.

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

It buys content outside your codebase, so a marketer can publish a page without a developer, a pull request or a deploy queue. A headless CMS keeps the content store separate from the rendering layer 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 will edit content without a developer anyway, you're paying a subscription and a maintenance cost for a workflow you don't use. Consider a hypothetical two-person startup where the founder writes the copy and the engineer commits it: that team needs a folder, not a CMS. The moment someone who has never opened a pull request needs to publish on their own schedule, the answer changes.

Contentful vs Sanity vs Payload: Which Pricing Model Fits Your Team?

Sanity bills per editor seat plus usage, Strapi Cloud bills flat tiers by API volume, and Payload is free software you host yourself, so the cheapest option depends on how many editors and how many requests you have. The figures below come from the vendors' own pages.

Two things follow from that table, and both are my arithmetic, not vendor claims. A four-person marketing team on Sanity Growth pays 4 × $15 = $60 a month before overage, and the free tier already covers up to 20 seats if you don't need the Growth roles or private datasets. The flat tiers on Strapi Cloud don't grow with your editor count, but they do grow with your request volume, so a busy site or a build that fetches heavily belongs on the request row of your comparison.

Contentful is the gap. Its pricing page returned an HTTP 429 error to automated requests on 30 September 2026, so I can't quote its current plan limits and won't repeat numbers from third-party roundups. Open Contentful's pricing page yourself and compare on four rows: users, roles, locales and API limits. The locale and role rows are the ones teams tend to discover late, and Sanity's page lists unlimited locales even on the free plan.

Try the arithmetic with your own headcount before you trust any summary. Twelve editors on Sanity Growth come to 12 × $15 = $180 a month, while a Strapi Cloud tier stays at its listed price whatever the seat count, so the crossover depends on your request volume and on which roles and features you need. A table like this only answers the billing question. It says nothing about editor experience, which is why the last step of the procedure below puts a real editor in front of the tool.

Payload is a different kind of bet

Payload moves the risk from vendor pricing to your own hosting and upkeep. Its documentation describes a framework built on Next.js where one config gives you an admin panel, a database with migrations, and REST and GraphQL APIs in a single codebase, with MongoDB and PostgreSQL supported. For a Next.js team that already runs Postgres, that is a clean fit.

Figma announced its acquisition of Payload on 17 June 2025, saying Payload will remain open source and that nothing is changing for users right away. The same post says Figma plans to build a CMS for Figma Sites using Payload's backend. This suggests the roadmap will now weigh a design tool's needs alongside those of B2B marketing teams, though nobody has announced a conflict. The project is still shipping: the npm registry lists payload 3.90.2, published on 23 September 2026.

Hosting changed as well. Payload's Cloud page says deployment of new projects is paused and recommends self-hosting on any provider you prefer, so a new project means you deploy and patch it yourself.

When Is Markdown in Your Repo the Right CMS?

When your editors are comfortable with git, or when a small dashboard on top of git is enough for them. Outstatic's docs describe a CMS for Markdown websites that writes to your GitHub repository, with no traditional database, and that works with any GitHub repository, including Astro and other static generators.

Because content lives in git, it's versioned, reviewable in a pull request and published through the pipeline you already have. The trade-off follows from the design, and this part is my inference: every publish is a commit, so publishing goes through your build and deploy, and features like scheduled publishing or per-field validation are things to check in the docs before you commit. If a marketer publishes twice a week, that's fine. If they publish six times a day, test the workflow first.

Pizzeria Bestek is an ordering platform, not a marketing site, but its case study shows the constraint that decides these choices. It's a React and Supabase build in four languages, and the owner runs a kitchen, so the admin workflow was reduced to opening an email and clicking CONFIRM or DECLINE. Ask what the equivalent is for your editors: if the honest answer is "they will not learn a dashboard", pick the lightest tool that works.

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 warning sign is a catch-all richTextBlock field added to hold whatever the last page needed. Once it exists, every future page uses it, and your content is unstructured prose again.

How Do You Choose a Headless CMS for a SaaS Marketing Site?

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 is a short procedure.

1. Count the humans who will edit without a developer in the next twelve months. Zero means Markdown in the repo, and you can stop.
2. Count your locales, then check each vendor's page for locale limits on the plan you'd buy.
3. Decide whether you'll maintain a database and a deployment. Yes points toward Payload, no points toward a hosted API.
4. Estimate your page count at 24 months and compare your expected API calls against the quota of the plan you'd buy.
5. Only then open the editor UX, with the person who will use it daily sitting beside you.

Whichever route you choose, write down the trigger that would make you revisit it, such as a second locale, a first non-technical editor or a page count that doubles. A decision with a stated review trigger is easier to change calmly than one you only question after a launch goes wrong.

Step 1 is the same discipline that drives a SaaS MVP stack decision, and teams often skip it. My breakdown of the best CMS options for marketing sites goes deeper on individual tools, and the Contentful vs Webflow comparison covers the fork between a headless setup and a visual builder.

The build step can hit your API limits

Static generation fires many requests during a build. In a Next.js discussion started in October 2020, developers report HTTP 429 responses from rate-limited APIs during builds, and share workarounds: setting workerThreads: false and cpus: 1 under experimental in next.config.js, adding delays, and retrying with backoff. Newer Next.js versions list experimental staticGeneration* options for retry count and concurrency, which the docs say are not recommended for production yet.

Those are user reports and an experimental feature, so treat them as things to try, not guarantees. The cheaper fix is design: fetch the content set once per build and resolve each page from memory, and cache repeated queries. Then compare the request row in the table against your page count, since a pipeline that rebuilds two thousand pages on every merge can spend a plan's included requests faster than you'd expect. Sanity's own docs state that cached CDN responses have no rate limit, which is a reason to read each vendor's limits page and not only its pricing page.

How many people will touch your marketing content next quarter, and which of them has never opened a pull request?