Disclosure: we're a Payload partner, and we steer clients away when it doesn't fit. Here's why Payload questions whether the headless category itself is right.
Disclosure: Distinction is a Payload CMS implementation partner. We recommend it where it genuinely fits, and we actively steer clients away from it when it doesn't. I wanted that stated upfront.
If you're a technical director or head of digital at a mid-sized B2B service firm, there's a decent chance you've already run a headless CMS evaluation this year. You've probably looked at Contentful, Sanity, maybe Strapi. You've sat through the demos, compared the pricing models, debated the trade-offs with your development team. And you've arrived at a shortlist that feels reasonably complete.
We've evaluated the main headless options. We don't need to add another one to the list.
I'd push back on that - not because the platforms you've evaluated are bad, but because Payload CMS occupies a position in the market that's genuinely different from all of them. Different enough that evaluating it isn't about adding another option to an existing category. It's about asking whether the category you've been evaluating in is actually the right one for what you're building.
That's a bold claim, so let me back it up.
From the outside, headless CMS platforms look interchangeable. They all separate content from presentation. They all offer APIs. They all claim developer-friendliness. But under the surface, the architectural decisions these platforms have made diverge in ways that matter enormously once you're twelve months into a build.
The mainstream headless options - Contentful, Sanity, Storyblok - are built around a SaaS model. The vendor hosts your content. The vendor controls the API layer. The vendor manages the infrastructure. You get a polished editing experience, a well-documented API, and a pricing model that starts friendly and scales with usage.
This works brilliantly for a lot of use cases. If you need a content layer for a marketing website, or a blog platform your editors can manage independently, or a lightweight content API for a mobile app - SaaS headless is genuinely excellent. I'm not here to knock it.
But there's a set of constraints baked into that model that only become painful when your use case gets more complex. Data residency is one. If you're in financial services or legal, the question of where your content physically lives and who has access to it isn't academic - it's a compliance conversation that SaaS platforms can make genuinely awkward. Customisation depth is another. Most SaaS headless platforms let you extend through plugins and webhooks, but there's a ceiling. When you need the CMS to do something the vendor hasn't anticipated, you're either waiting for their roadmap or building workarounds.
And then there's cost at scale. SaaS headless pricing tends to be usage-based - API calls, content items, users. For a 50-page marketing site, the numbers are trivial. For a client portal serving thousands of users with dynamic, permissioned content, the maths changes fast. I've seen mid-market firms get a bill that's two or three times what they budgeted because their usage pattern didn't match what the pricing tier assumed. One firm - a financial services business, around 200 people - had been on Contentful for eighteen months when the renewal came in. The number on the invoice wasn't what anyone had planned for. Their head of digital described it to me as "the moment the board stopped trusting us on technology costs." That's a rough conversation to be in.
Payload takes a fundamentally different position. It's open source. It's self-hosted. It's TypeScript-first. And, this is the bit that matters most, the application logic, the content model, and the admin UI all live in the same codebase as the consuming application. The CMS isn't a separate system you integrate against. It's part of your application.
That changes everything about how you build with it. And it changes everything about who should be building with it.
I want to be careful here. This piece isn't written for developers - it's written for the people who make platform decisions and need to understand why their development team might be pushing for a particular direction. So I'll keep the technical detail at the level where it informs a decision, not where it reads like documentation.
TypeScript-native architecture. Payload is built in TypeScript from the ground up. That's not the same as a platform that "supports" TypeScript or has "added TypeScript definitions." The difference matters in practice. Your development team gets full type safety across the entire stack, which means an entire class of runtime errors simply can't happen. If you've ever had a deployment break because someone changed a content field name and the frontend didn't know about it - that's exactly the kind of thing TypeScript-native architecture prevents. Development teams typically lose somewhere between a quarter and a third of their productive time to technical debt. Payload's architecture eliminates one of the most common sources of it in CMS-driven projects.
Self-hosted. Your content lives on your infrastructure. Your cloud environment, your security controls, your data residency. For firms operating under regulatory requirements - and if you're in financial services or legal, that's you - this isn't a nice-to-have. We migrated a US bank away from Contentful partly for this reason. Costs were climbing unpredictably, but the real driver was that their compliance team couldn't satisfy audit requirements with content infrastructure they didn't control. The conversation that kicked it off was actually pretty blunt - the bank's SVP of Digital called us and said something like "we've just been told by our auditors that we can't demonstrate chain of custody on our content environment, and Contentful can't fix that for us." We moved them onto Payload within their own Azure environment. Costs dropped by more than 60% annually. More importantly, they could finally answer the auditor's questions.
Code-first content modelling. In most SaaS headless platforms, you define your content model through a GUI - clicking around an admin panel to create fields and relationships. That's intuitive, but it creates a problem: the content model lives in the vendor's system, separate from your application code. Change the model, and your build might break. Payload flips this. The content model is defined in code, version-controlled alongside the application, and deployed through the same pipeline. Your CMS configuration and your application code can never drift apart. For any firm that's experienced the "someone changed a field in the CMS and now the site's broken" problem - and most have - this is a meaningful shift.
A fully customisable admin UI. Payload generates its admin interface from the content model. But unlike most CMS platforms where the admin UI is what you get, Payload's interface can be fully customised using the same React components the rest of the application uses. The CMS adapts to the application, rather than the application adapting to the CMS. If you're building a client portal where internal teams need to manage complex, permissioned content alongside business logic, this is where Payload really starts to separate from the pack.
I've written separately about the broader question of headless versus hybrid architectures, which is worth reading before you commit to any specific platform. But assuming you've already concluded that headless is the right direction, here's where Payload earns its keep.
Custom client-facing portals. When the content layer needs to be deeply integrated with business logic - user permissions, dynamic content rules, transactional data - Payload's single-codebase architecture eliminates the integration complexity that makes portal projects expensive and fragile. We built a portal for a professional services firm where the content management, user authentication, and business rules all lived in the same application. No API stitching, no middleware, no "the CMS can't do that so we'll build a workaround." Their IT team had spent two years managing exactly those workarounds on the previous platform. They couldn't quite believe how much simpler it was.
Digital products where you want to own the stack. If you're building a product - not just a website - and you want to own the infrastructure without paying SaaS costs that scale with usage, Payload gives you that. Most organisations are already burning a significant chunk of their IT budget on maintaining legacy systems. The last thing you need is another platform whose costs compound unpredictably as you grow.
Complex integrations. When the CMS needs to act as an orchestration layer across multiple data sources - pulling from a CRM here, a pricing engine there, a compliance database somewhere else - Payload's architecture makes it a first-class participant in the integration rather than a separate system you're pushing data into.
Teams with strong TypeScript capability. If your development team already works in TypeScript and Next.js, Payload feels native. No context switching, no learning a vendor-specific SDK, no "the CMS does things differently." It's just more of the same stack they already know.
Here's where I need to be straight with you, because the credibility of everything I've said above depends on being honest about where Payload falls short.
The ecosystem is smaller. Contentful has been around since 2013. Sanity since 2017. Payload became publicly available in 2022. The community is growing fast, but it's significantly smaller. Fewer plugins. Less third-party tooling. A smaller pool of developers with direct experience. If you're hiring, finding Payload-experienced developers is harder than finding Contentful-experienced ones. That's just a fact.
Self-hosting means self-managing. You're responsible for infrastructure, security patching, uptime, backups, and scaling. If your firm doesn't have DevOps capability - or a partner who provides it - this is a serious constraint. The SaaS platforms handle all of this for you, and there's genuine value in that. Don't underestimate it.
But our dev team loves it, so the content editors will just have to adapt...
I've heard this one. It doesn't end well. The code-first model is brilliant for developers. For a marketing manager who just wants to update a page, it can feel less intuitive than the polished editing experiences that Contentful or Sanity offer out of the box. You can customise Payload's admin UI to improve this significantly, but it requires development effort. It's not free. I've seen firms ignore this limitation because they fell in love with the developer experience, and then watched their content team quietly stop using the platform and revert to emailing developers for every change. Which rather defeats the point.
Platform maturity. Payload has been acquired by Vercel, which gives it strong backing and a clear strategic direction. But it's still younger than the established alternatives. If long-term vendor stability is a primary concern - and for a platform you'll depend on for five or more years, it should be - this warrants honest conversation.
Two-thirds of large tech programmes miss targets on time, budget, or scope, according to BCG. Platform selection errors are a significant contributor to that statistic. So here's how I'd think about whether Payload belongs on your shortlist.
Payload is likely the right fit if you have a mature TypeScript development team (or a delivery partner with demonstrated Payload experience), if your use case genuinely requires self-hosting or deep application integration - not just "it would be nice," but a real requirement driven by compliance, cost, or architectural need - and if you have the DevOps capability to manage infrastructure reliably. The sweet spot is when the CMS needs to be part of the application, not adjacent to it.
We're a law firm. We just need a CMS that our marketing team can use without filing a support ticket every time they want to change a heading.
Then Payload probably isn't for you, and I'd say that without hesitation. If your primary need is a polished content editing experience for non-technical teams, if you don't have the development resource to own and maintain the platform, or if your use case is well-served by the out-of-the-box capabilities of a SaaS headless CMS - go with one of those. Seriously. The right platform for your situation is the one that fits your team and your use case, not the one with the most impressive architecture.
There's a companion piece on what really matters when choosing between Kentico and its competitors that covers the hybrid DXP side of this decision, which is worth reading if you're still working out whether headless is even the right architecture for you. And if you want the strategic framing before getting into any of this technical detail, I've written about why your next CMS decision matters more than you think - start there.
Payload projects require a different kind of delivery governance than typical CMS implementations. Because the development team owns more of the stack - hosting, security, the admin UI itself - the way you manage scope, risk, and change needs to reflect that. The team isn't just configuring a vendor platform; they're building on a framework. That's more powerful, but it also means more responsibility. I've written about how to structure delivery for developer-owned platforms, which is worth a read if you're seriously considering this path.
If you want to assess whether Payload is the right fit for your specific use case and team capability, we've put together a one-page Payload fit assessment that makes the decision criteria explicit. It covers five dimensions - team capability, use case complexity, hosting ownership, content editor needs, and ecosystem requirements - and gives you a clear steer on whether it's appropriate for your situation. It's designed to be genuinely useful even if the answer is "Payload isn't for you." Because sometimes the most valuable thing an assessment can do is save you from a platform that's impressive but wrong.
