Comparisons

A headless CMS for help text

· Prices and facts as published by each vendor on

A headless CMS can serve help text. Contentful, Sanity and Prismic all store content behind an API, your application fetches it while it runs, and a change goes live without a release. If your team already runs one for the marketing site, putting tooltips and error messages in it is a reasonable first thought.

Two things decide whether that holds: who is allowed to edit, and how much of the help model you build yourself.

Roles are the first wall

The person who maintains your help text usually should not be able to edit your marketing pages, your product data or your content model. That restriction is a role, and roles sit higher up the price list than seats do.

Prices and seat counts as published by each vendor on 22 September 2026:

PlatformFree planPaid entryRoles
Sanity$0 forever, up to 20 seatsGrowth, $15 per seat per month, up to 50 seats2 permission roles on Free, 5 on Growth (Admin, Viewer, Editor, Developer, Contributor); custom roles on Enterprise
Prismic$0 per month per repository, paid annually, 1 userStarter $10 per month per repository, paid annually, 3 users; Small $25, 7 usersUser roles from Medium at $150 per month; custom roles on Enterprise

Contentful publishes a free tier with a small number of fixed roles and moves finer permissions up its paid plans. Its pricing page did not load for us on the day we checked, so we are not repeating figures we could not read at the source.

The fifth person is where this gets concrete, and the two platforms answer it differently. On Sanity the fifth seat costs nothing, because Free includes twenty; what Free does not include is a role between administrator and viewer, so the colleague who should edit help text and nothing else moves you to Growth at $15 per seat per month, and a role shaped to your own content model is an Enterprise conversation. On Prismic the fifth user means the Small plan at $25 per month per repository, and user roles of any kind begin at Medium, at $150 per month.

None of that is unreasonable pricing for a platform that holds your whole site. It does mean the free tier that made this look cheap is usually the tier where everyone who can edit can edit everything.

What you build on top

The content model. A headless CMS has no idea what a help topic is. You define the type, the fields, the validation and the relationships. That is an afternoon for a developer who knows the platform, plus the afternoons that follow when the model turns out to need steps, warnings, or a piece of text that appears in three places.

The address. Help text is requested by a stable key. In a headless CMS that is a field you add, and two entries can carry the same value unless you build the check yourself. When that happens your application gets whichever entry the query returned first, and the wrong tooltip appears on a screen nobody tested.

Missing-key behaviour. What your app does when an entry is absent, unpublished or deleted is yours to design, in every component that asks for text.

The editing surface. Your writer opens a general content editor with every content type in it. Narrowing that view to help text, and to the fields that matter, is configuration work, and on most platforms it is permission work as well.

A register of what exists. Which keys your product asks for, which of them are published, and which are still missing. That is a query you write and a dashboard you maintain.

What stays hard after you build it

Structure that knows what help is: steps, warnings, prerequisites, a result. You can model those as fields. What the model does not give you is an editor that treats them as what they are, or delivery that hands them to your application in a documented shape.

The same goes for reuse. A button label that appears in forty sentences and gets renamed once needs identity, not a copy. A general content model can hold a reference between entries; keeping one consistent inside running text is a different job.

When a headless CMS is the right choice

It fits well when:

That last point is worth taking seriously. It is true for plenty of small teams, and while it holds, the free tier of a headless CMS is hard to beat.

When it stops fitting

It stops fitting when help text gets its own writer, because that is the moment roles start costing money, and when the help outgrows a title and a body, because that is the moment you start building a content model for something that already has one. From there the choice is between building the missing pieces and moving help text into a system made for it. HelpCCMS is one: topics with steps, warnings and reusable parts, addressed by a help key that belongs to exactly one topic.

How to manage in-app help sets out the options across four levels, from strings in your repository to content a writer publishes alone.

Sources