Two years ago, I sat in a board presentation where the CTO of a mid-sized financial-services firm made his case for a headless CMS. He had spent six weeks on it. The spreadsheet on screen had 47 criteria, colour-coded, weighted and averaged. His conclusion was Contentful, by a clear margin.

I remember thinking it was thorough. I also remember thinking it answered the wrong question.

Eighteen months later, the firm was spending much more than expected on content operations. Editors filed support tickets for routine changes. The CTO, a sharp and conscientious person, was asking whether a move was feasible. Contentful had done what the evaluation said it could do. The decision had failed to give enough weight to what the organisation needed people to do every week.

I could tell a similar story about a Payload implementation where nobody had properly planned for deployment and operational ownership. The platform was not the central problem in either case. The decision process was.

A feature matrix can make Contentful and Payload appear equivalent. Both can manage structured content and expose it through APIs. That overlap conceals a fundamental distinction. Contentful is a managed content platform with its own service boundaries and commercial plans. Payload describes itself today as an open-source Next.js backend: its CMS, application code, admin interface and data model can live in a codebase you own and deploy. The choice is as much about the responsibility you want to carry as the features you want to buy.

What Contentful is buying you

Contentful is an established managed platform. The supplier operates the core service, provides an editorial application and offers a range of content, governance, localisation and enterprise capabilities. That can be attractive when the organisation wants a clear vendor relationship and does not want its engineering team to run the CMS infrastructure.

The editorial and governance proposition deserves real weight. Contentful's current plans distinguish among roles, locales, environments, workflows, scheduled publishing and other team features. Its published pricing and plan comparison makes clear that entitlements vary by plan and space. Enterprise arrangements are custom, while lower plans have defined limits and feature sets.

Contentful also provides APIs, documentation and an extension model around a managed product. For a firm with common integration needs and a preference for configured services, that can reduce the amount of platform code it owns.

The trade-off is that service boundaries, entitlements and commercial terms matter. The current pricing model includes measures such as users, roles, locales, API calls, bandwidth and spaces, with different treatment across plans. Do not price a production content operation from a starter project. Model the expected number of editors, environments, markets, records, traffic and governance requirements, then ask the vendor to confirm the commercial treatment in writing.

Customisation is possible, although it takes place within Contentful's platform and extension points. That structure can be valuable discipline. It can also become a constraint when the organisation needs unusual workflow logic, a deeply bespoke editing interface or application behaviour that falls outside the product's preferred model.

Exit is another design requirement. Content can be extracted, but a migration includes more than entries. Content models, references, localisation rules, roles, workflows, extensions, assets and front-end queries all create effort. Ask for an exit design before signing a long commitment: what is standard data, what is platform configuration and what would have to be rebuilt elsewhere?

What Payload is asking you to own

Payload has changed materially since simple comparisons described it as a small, self-hosted headless CMS. Its current product documentation presents a Next.js-based framework that generates an admin panel, database schema, APIs, authentication, access control and other application capabilities from configuration. Payload joined Figma in 2025, while the company says the open-source core and self-hosting capability remain.

That model gives engineering teams substantial control. The schema and application live in code. The team can define document- and field-level access, customise the admin interface and place CMS behaviour beside the front-end or application logic. This can suit a client portal, knowledge product or regulated workflow where content is only one part of the application.

Open source does not mean free to operate. The Payload deployment guidance says most projects also need a database, permanent file storage, email and a CDN, depending on the implementation. The firm must decide who handles deployment, security updates, backups, monitoring, performance, availability and incident response. Managed and enterprise support options may change that allocation, so evaluate the exact service being proposed rather than the licence label.

The editorial experience should be tested, not assumed. Payload now documents live preview, versions, drafts, scheduled publishing and a highly customisable admin panel. Those capabilities undercut older claims that it is inherently unsuitable for non-technical editors. They also require configuration and implementation choices. Contentful's managed interface may work well sooner; Payload may allow a team to build an experience closer to its workflow. A prototype with real content and real editors will tell you more than a screenshot comparison.

Payload's flexibility can become a long-term engineering commitment. A heavily customised admin interface or access model belongs to the firm. That is an asset when it differentiates the service, and a burden when it reproduces standard CMS functions with bespoke code.

The five decision criteria that matter

The useful question is which operating model fits your reality. Assess five things before scoring features.

1. Total cost over a realistic period

Compare more than year-one implementation and headline licence cost.

For Contentful, model the plan, spaces, users, locales, environments, traffic, support and any additional products required. For Payload, include hosting services, engineering time, security and dependency maintenance, monitoring, support and the work needed to create the desired editorial experience. For both, include integrations, migration, ongoing improvement and a plausible exit.

Run several scenarios. What happens when a second market is added, traffic grows, the portal needs authenticated content or the delivery partner changes? A single five-year total can hide assumptions that deserve a board decision.

2. Technical ownership

Can the firm own and operate a code-led platform? "We could hire somebody" is different from having an accountable team and budget.

Payload can be a strong fit when capable developers want its application framework and the organisation is prepared to maintain what it builds. Contentful can be stronger when engineering wants to consume a managed content service and concentrate on experiences around it. Neither removes the need for technical ownership of integrations, security, the front end and release quality.

3. Integration and application complexity

List what the CMS must exchange with CRM, identity, document, marketing, compliance or client systems. Distinguish common integrations from behaviour unique to the firm.

Contentful's established platform and ecosystem may reduce effort for supported patterns. Payload's code-level control may suit unusual application logic. "Flexible" is not a decision criterion until the team can name the constraint it needs freedom from.

4. Editorial work

Observe who creates, reviews, localises, approves and publishes content. Include the difficult work: a campaign spanning markets, a regulated correction, a reusable biography, an embargoed report or an urgent change outside office hours.

Give editors a representative prototype. Count steps and interventions. Check preview, permissions, scheduling, search, validation, bulk work and recovery from mistakes. A polished demo with sample blog posts will not expose the workflow that drives operational cost.

5. Supplier and platform trajectory

Contentful is a proprietary managed service. Payload is open source and part of Figma. Those are different dependency profiles, and both can change.

Procurement should examine financial and operational assurance, support commitments, security responsibilities, data processing, roadmap dependence and exit. Open source can provide code access and deployment choice; it does not guarantee that the firm has the skill to exercise them. An established SaaS vendor can reduce operational work; it does not eliminate commercial lock-in.

The agency incentive problem

There is an awkward factor in most CMS recommendations: the adviser has an operating model too.

An agency usually has a platform it knows best, internal tools built around it and people whose skills are deepest there. That expertise is a genuine benefit. It also shapes which risks the agency notices and which work it finds commercially attractive.

We have seen agencies recommend a large managed platform to firms whose needs were much simpler. We have also seen developer-led teams recommend Payload without allowing for the client's ability to maintain the implementation after handover. A bespoke framework can create an even stronger dependency on its creator.

At Distinction, we work with Contentful, Payload, Kentico, Umbraco and other platforms. That breadth does not make our advice neutral by magic. Ask us the same questions you should ask any adviser:

  • Which requirements led to this recommendation?
  • Which platform risks will your team own after launch?
  • What recurring revenue or specialist dependency does this choice create for you?
  • What would make you recommend the alternative?
  • How can another capable partner take over the implementation?

A confident recommendation should survive those questions.

When neither is the right answer

Some firms do not need a headless content platform.

Headless architecture earns its place when content must serve distinct channels, the front end needs an independent engineering lifecycle or important integrations benefit from a clean content API. It can also be a sensible part of a broader application.

If a 200-person service firm needs a public website, an article library and a straightforward enquiry route, a conventional CMS with a strong editing experience may be a better choice. The marketing team may value visual page composition and low support dependence more than separation between content and presentation.

We spoke with a consultancy that had been told it needed headless because the delivery team wanted a particular front-end framework. The result was architecturally sophisticated and awkward for a small marketing team publishing case studies. The lesson is broader than that one case: a developer preference needs a business consequence before it becomes a requirement.

A practical decision

Contentful is more likely to fit when the firm values a managed service, mature vendor support and a capable editorial environment; its requirements sit comfortably inside the platform; and the projected plan and usage costs are acceptable.

Payload is more likely to fit when the CMS forms part of a custom digital product; the firm has strong engineering ownership; code-level control over data, access and the admin experience creates specific value; and the operating responsibilities are funded.

Neither is likely to fit when the requirements are straightforward, multi-channel reuse is hypothetical or a headless setup would make editors more dependent on developers without improving a meaningful customer outcome.

Return to the CTO with the 47-criteria spreadsheet. The problem was not diligence. It was effort pointed at what the products could do, with too little attention on the work the organisation would have to do around them.

Spend less time averaging feature scores and more time observing your own operation. What can your team maintain? How will costs change across credible scenarios? What does editorial work look like on a difficult Tuesday? Where do you need control, and where would you prefer a supplier to take responsibility?

The platform that fits those answers is the stronger choice, even when it is not the one with the most impressive demonstration.