Disclosure: we're a Payload partner, and we talk firms out of it regularly. Here's exactly where it shines, and where choosing it wastes money.
Let me be upfront about something before we get into this: Distinction is a Payload partner. We've built on it, we like it, and we recommend it regularly. Which is exactly why this piece needs to exist - because we also talk people out of choosing Payload on a fairly regular basis, and I think that's worth writing down.
There's a version of this article that reads like a product brochure. Payload is open-source, endlessly flexible, developer-friendly, built on a modern stack - all true. But none of that tells you whether it's right for your project, your team, and your actual operational reality twelve months from now. The gap between "this is a great CMS" and "this is the right CMS for us" is where a lot of money gets wasted.
I've seen firms commit to Payload for reasons that had very little to do with their own requirements and quite a lot to do with the enthusiasm of the agency pitching it. That's not a dig at Payload. It's a dig at how CMS decisions get made.
Payload is built for developers first. That's not a marketing line - it's an architectural decision that runs through the entire product. If you've got a strong internal development team or a long-term delivery partner with real Node.js and TypeScript capability, Payload gives you a level of control that most CMS platforms simply don't.
Complex data models. If your content structure is more than pages-with-fields - if you're dealing with interconnected data types, conditional relationships, multi-layered taxonomies - Payload handles that with an elegance that more traditional platforms struggle with. We rebuilt a content architecture for a financial services client recently where the old CMS had 14 content types held together with custom plugins and prayer. Research notes, regulatory disclosures, author profiles, market commentary, fund data - all tangled up in a way that made every deployment feel like defusing a bomb. Payload's schema-driven approach meant we could model those relationships in code, version-control them, and deploy changes without the "please don't touch that field, it'll break everything" anxiety that had plagued the team for years. The first time the content team published a research note without filing a support ticket, the head of digital sent us a voice note. Genuinely delighted.
Integration-heavy environments. When the CMS needs to talk to a CRM, a compliance system, an LMS, a client portal, and possibly a couple of third-party APIs, Payload's code-first approach means those integrations are built as proper application logic, not bolted-on plugins. I've written separately about why composable architecture matters for firms with complex technology stacks - Payload is one of the platforms that makes that approach practical rather than theoretical.
Self-hosted requirements. This one matters more than people think, particularly in regulated industries. If your compliance team needs the CMS running inside your own cloud environment - your Azure tenant, your AWS account, under your security policies - Payload gives you that. We migrated a US bank off Contentful partly for this reason. They were on a SaaS CMS with content sitting in someone else's data centres, and their compliance team had started asking uncomfortable questions about data residency and audit trails. Contentful couldn't answer those questions in a way that satisfied the regulators. Payload, self-hosted inside their own AWS environment with role-based access controls feeding directly into their existing compliance systems, could. I've covered that comparison in more detail in a separate piece on Contentful vs. Payload, if you're weighing those two specifically.
Projects where the frontend is the product. If you're building something genuinely custom - a client portal, a personalised content experience, a complex application with CMS-managed content woven through it - Payload stays out of your way in a manner that opinionated platforms don't. It's a content backend, not a website builder. For certain projects, that distinction is everything.
Right. This is the bit that matters, and it's the bit that gets glossed over in most agency recommendations.
Small editorial teams who need simplicity. If your marketing team is three people and their primary need is to publish blog posts, update service pages, and manage events without filing a support ticket, Payload's admin UI - while it's improved significantly over the past year - is not yet as intuitive as something like Umbraco or even a well-configured WordPress setup. It's getting better. The recent admin panel redesign has closed a lot of that gap. But "getting better" and "good enough for a non-technical editor who publishes content twice a week" are different things.
I was with a mid-sized consulting firm a few months back. Their marketing lead had been told by their agency that Payload was the future and they needed to get on board. She pulled up the admin interface during our assessment call and said, honestly, "I don't even know where to start." She's not a technophobe - she'd been managing a WordPress site perfectly well for four years. I felt a bit awkward, if I'm honest, because we'd been about half an hour away from recommending Payload ourselves before she opened that screen. The tool wasn't wrong. It was wrong for her.
Firms without ongoing developer access. This is the one that catches people out. Payload is configured in code. The content schema, the access control, the hooks and validations - they live in a codebase, not in a GUI. Fantastic if you have developers who can maintain and evolve that. A real problem if your plan is to build it, launch it, and then not touch the codebase for eighteen months.
I'll put it bluntly: if your firm doesn't have an internal developer or a retained technical partner, and your plan is to commission a Payload build and then "just use it," you're going to hit a wall the first time you need a new content type, a workflow change, or a field added to an existing model. With a traditional CMS, your marketing manager can often handle that. With Payload, it's a code change and a deployment.
We learnt this the hard way on one project - a professional services firm where the original brief was clear, the build went well, and then six months post-launch they came back needing a fairly routine taxonomy change. No retained partner, no internal dev. What should have been a two-hour job turned into a three-week conversation about who was going to do it and what it would cost. Entirely avoidable. We now have that conversation before we start, not after.
Projects where editorial workflow is the priority. If your biggest pain point is approval chains, scheduled publishing, multi-author workflows, content staging, and preview environments - Payload can do these things, but they require more setup than platforms that ship with them out of the box. A mature Kentico or Umbraco instance gives you those editorial workflows on day one. With Payload, you're building or configuring them. Fine if you planned for it. Not fine if you assumed it would just be there.
When the community and ecosystem matter. Payload's community is growing fast, and the documentation has improved enormously. But let's be honest - it's not WordPress, it's not Umbraco, and it's not Kentico. If you need a plugin for something niche, or you want to hire a freelancer who already knows the platform, the pool is smaller. That's a practical consideration, not a criticism. Every emerging platform goes through this phase. But if you're making a decision today, the ecosystem you have today matters more than the ecosystem someone promises you'll have in two years.
Here's something I want to handle carefully, because it's not about pointing fingers. It's about a structural dynamic that affects CMS recommendations across the industry.
Payload is genuinely exciting to build with. Modern stack, clean API, elegant developer experience. If you're a senior developer at a digital agency and someone asks you to recommend a CMS, there is a natural - and not malicious - bias towards recommending the thing you'd most enjoy working on. Developers who've spent years wrestling with WordPress plugins or fighting Sitecore's deployment pipeline are understandably drawn to something that feels clean and modern.
That's not corruption. It's human nature. But it means the recommendation you're receiving might be weighted towards developer experience rather than your experience - the experience of the people who'll live with this platform every day after the agency moves on to the next project.
Our agency recommended Payload. It must be right for us.
Maybe. But ask yourself: did they also explain who'll maintain the codebase after launch? Did they walk you through what your content editors' daily workflow will look like? Did they present alternatives and explain why Payload was better for your specific situation, or did they present Payload and explain why it was good in general?
There's a meaningful difference.
I've written separately about how to choose a digital platform when everyone has an opinion - it covers a vendor-neutral framework for evaluating CMS options that applies regardless of which platform you're leaning towards. Worth a read if you're mid-decision and feeling like everyone has an agenda - including us - that's probably the right instinct. We've published a vendor-neutral decision framework that might help cut through the noise. Because the most expensive CMS decision isn't choosing the wrong platform. It's choosing any platform before you've properly understood what you actually need.