Two years ago, I sat in on a board presentation where a CTO at a mid-sized financial services firm was making his case for a headless CMS. He'd been at it for six weeks. The spreadsheet he put up on the screen had 47 criteria - colour-coded, weighted, averaged. The room was impressed. His conclusion: Contentful, by a clear margin.
I remember thinking it was thorough. I also remember thinking it was answering the wrong question.
Eighteen months later, the firm was spending three times what they'd budgeted on content operations. Their editorial team was filing support tickets to do things that should have taken five minutes. And the CTO - good bloke, genuinely sharp - was quietly asking us whether migrating to something else was feasible. Not because Contentful had failed him. It hadn't. It was because the decision had been made on what the platform could do, not what his organisation actually needed it to do.
I could just as easily tell you about a Payload implementation that went sideways because nobody had properly thought through the hosting and DevOps overhead. The platform wasn't the problem in either case. The decision process was.
The feature comparison shows they're basically equivalent. What's the real difference?
You're not wrong to notice that. On paper, Contentful and Payload look remarkably similar. Both are headless. Both offer a content modelling layer, an API-first architecture, and the ability to deliver content to multiple channels. Both have active development communities. Both can, technically, do most of what you need a modern CMS to do.
But "technically capable" and "right for your firm" are very different things. Confusing the two is how organisations end up locked into platforms that work fine in demo environments and create quiet misery in production.
Contentful has been around since 2013. It's mature, well-funded, and has an ecosystem that reflects over a decade of enterprise adoption. If you're evaluating headless CMS platforms and your organisation values stability, vendor support, and a polished editorial interface, Contentful is going to look very appealing. Rightly so.
The content modelling is genuinely strong. The editorial experience - the day-to-day interface your marketing and content teams actually interact with - is one of the better ones in the headless space. There's a marketplace of integrations, solid documentation, and enterprise-grade support tiers that give CTOs the confidence to put it in front of a board without worrying about the "what if the vendor disappears?" question.
So far, so good.
Here's where it gets more complicated. Contentful's pricing model scales with usage - entries, environments, API calls, users. For a small team publishing a few hundred pages, the numbers are manageable. But I've seen mid-market firms hit genuinely eye-watering bills once they start scaling content operations, adding locales, or running multiple environments for staging and testing. One firm we assessed was paying north of £80,000 a year in Contentful licensing alone. Not their entire tech stack. Just the CMS.
The other trade-off that doesn't show up in feature comparisons is customisation. Contentful is a SaaS platform. You're renting space in their infrastructure, playing by their rules. That's fine if your requirements fit neatly within what they've built. Custom field types, bespoke workflow logic, deep integration with internal systems - all possible, but you're working within guardrails that someone else defined. For some organisations, those guardrails feel like helpful structure. For others, they feel like a straitjacket.
And then there's the lock-in question, which nobody likes talking about but everybody should. Your content models, your editorial workflows, your integrations - they're all built around Contentful's specific architecture. Moving away isn't impossible, but it's not trivial either. I've seen migration projects from Contentful take six months and cost more than the original implementation. Worth factoring in before you sign a three-year contract.
Payload is a different animal. Open-source, self-hosted (or cloud-hosted, as of more recently), and built with a developer-first philosophy that gives engineering teams a level of control that Contentful simply doesn't offer.
If your organisation has capable developers - and I mean genuinely capable, not "we have a junior dev who can update WordPress" - Payload is extraordinarily flexible. The data layer is yours. The admin panel is yours. The authentication, the access control, the API structure - all of it can be shaped to fit your specific requirements rather than the other way around. We've built some genuinely sophisticated implementations on Payload for clients in regulated industries where data sovereignty and custom workflow logic weren't nice-to-haves but compliance requirements.
The cost profile is also dramatically different. Because Payload is open-source, there's no per-seat, per-entry, per-API-call licensing model. Your costs are infrastructure and development time. For organisations with the technical capability to manage that, the total cost of ownership over five years can be a fraction of what Contentful would cost at equivalent scale. We've seen differences of 60% or more.
But Payload asks more of you. Hosting is your responsibility. Security patching is your responsibility. Performance optimisation, uptime monitoring, backup strategy - all yours. If you're a firm with a two-person IT team that's already stretched thin keeping the lights on, this isn't a minor consideration.
The editorial experience is also worth being honest about. It's improved significantly over the past couple of years, and for technically comfortable teams it's perfectly workable. But if you're comparing it directly to Contentful's editorial interface - particularly for non-technical content editors who just want to log in and publish a blog post without thinking about data structures - Contentful still has the edge. That gap is closing, but it hasn't closed yet.
The community and ecosystem are smaller too. Contentful has thousands of enterprise deployments, a large partner network, and a decade of Stack Overflow answers. Payload's community is growing rapidly, but if you hit an obscure edge case at 11pm on a Thursday, you're more likely to be reading source code than finding a pre-written solution.
So here's where I want to shift the conversation. Because if you've read this far, you might be thinking: "OK, Contentful is more polished but expensive. Payload is more flexible but harder. I already knew that." Fair enough.
The real question isn't which platform has better features. It's which platform fits your reality. And by reality, I mean five specific things.
Total cost of ownership over five years. Not the year-one implementation cost. The full picture. Contentful's licensing fees compound as you scale. Payload's infrastructure and development costs require ongoing investment in technical capability. Model both trajectories honestly, including the cost of the team or agency you'll need to maintain each one.
Your internal technical capability. This is the one that gets fudged most often. Be brutally honest. Do you have developers who can own and operate a self-hosted platform? Not "could we hire someone?" - do you have them now, and will you retain them? If the answer is no, Payload's flexibility becomes a liability rather than an asset. If the answer is yes, Contentful's constraints become an unnecessary tax.
Integration complexity. What does your CMS need to talk to? CRM? Marketing automation? A compliance system? A client portal? Contentful's marketplace and established patterns make common integrations straightforward. Payload's open architecture makes unusual integrations possible in ways that would be painful or impossible in Contentful. Which profile fits your needs?
Editorial team requirements. Who is actually going to use this thing every day? If the answer is a marketing team with limited technical confidence who need to publish content independently without developer support, weight the editorial experience heavily. If the answer is a technically literate team that values flexibility over hand-holding, the calculus shifts.
Vendor stability and trajectory. Contentful is a well-funded, established company with an enterprise customer base. Payload is open-source with growing commercial backing and an increasingly active community. Both are viable long-term bets. But your board's comfort level with open-source infrastructure should be part of the conversation, particularly in regulated industries where procurement and compliance teams have strong opinions about these things.
I want to raise something slightly awkward here, because I think it matters and nobody else is going to say it.
When you ask an agency to recommend a CMS, you're asking an organisation with its own commercial incentives to make a recommendation that serves your interests. Most agencies are honest. But most agencies also have a platform they know best, a platform they've built internal tooling around, and a platform where their team's skills are deepest. It would be strange if that didn't influence their recommendation, even unconsciously.
I've seen agencies recommend Contentful to clients who clearly needed something simpler because Contentful projects are bigger and more lucrative. I've seen agencies recommend Payload because their developers love it, without adequately accounting for the client's ability to maintain it after handover. And I've seen agencies recommend neither and push their own bespoke framework, which creates a dependency that's even harder to escape.
At Distinction, we work with both Contentful and Payload - along with Kentico, Umbraco, and others. We don't have a horse in this race, which is precisely why I can write this piece without it being a thinly disguised sales pitch for one platform. But if the agency advising you only works with one CMS, at least factor that context into how you receive their recommendation.
Here's the bit that most comparison articles skip entirely.
Not every organisation needs a headless CMS. I know that sounds odd in an article comparing two headless platforms, but hear me out.
Headless architecture makes sense when you need to deliver content to multiple channels - website, app, portal, digital signage, whatever. It makes sense when your development team wants to use a modern frontend framework independently of the CMS. It makes sense when your integration requirements demand a clean API layer between your content and your presentation.
But if you're a 200-person professional services firm that needs a website and maybe a resource library, and your marketing team wants to update pages without filing a Jira ticket - a traditional CMS with a good editing experience might be the better call. Something like Umbraco or a well-configured Kentico instance could give you 90% of what you need with significantly less complexity and cost.
I had a conversation last month with a COO at a consulting firm who'd been told by a previous agency that they "absolutely needed headless." When we dug into why, the answer basically boiled down to: the agency wanted to use React on the frontend. That's a developer preference, not a business requirement. The firm ended up on a platform that was architecturally sophisticated and operationally painful for a marketing team of three who just wanted to publish case studies.
If you're evaluating Contentful and Payload, step back and ask whether headless is genuinely the right architecture for your situation. If the answer is yes, great - this comparison matters. If the answer is "we're not sure," that's worth resolving before you go any further.
Let me simplify it, because I think there's a risk of overthinking this.
Contentful is likely the better fit if you need a mature, enterprise-supported platform with a polished editorial experience; your integration requirements are well-served by existing marketplace connectors; you have budget for licensing that scales with usage; and your technical team wants to focus on the frontend rather than managing CMS infrastructure.
Payload is likely the better fit if you have strong in-house development capability or a trusted technical partner; you need deep customisation or operate in a regulated environment with specific data sovereignty requirements; you're cost-sensitive at scale and willing to invest in infrastructure management; and your editorial team is technically comfortable or can be supported by developers.
And neither might be right if your requirements are straightforward enough that a traditional CMS would serve you well, you don't have clear multi-channel delivery needs, or the complexity of headless architecture would create more problems than it solves for your team.
The CTO I mentioned at the start wasn't incompetent. He was thorough, methodical, and genuinely trying to make the right call. The 47-criteria spreadsheet wasn't laziness - it was effort applied in the wrong direction. He'd optimised for the decision that looked defensible in a boardroom rather than the one that would actually work in production.
That's not unusual. We see it regularly - firms that are 12 or 18 months into a platform and realising it doesn't fit. The migration cost, the lost momentum, the internal credibility damage to the technology leader who championed the decision - it all compounds.
My honest advice if you're in the middle of this right now: spend less time comparing feature matrices and more time understanding your own organisation. What's your team actually capable of maintaining? What's your realistic budget trajectory over three to five years? What does your editorial workflow genuinely look like day to day - not in the aspirational version, but in the messy, real one?
The platform that fits those answers is the right one. Even if it's not the one with the best demo.