Distinction is a Payload partner. We build with the platform and have an incentive to see projects on which it works well. That is a reason to make the selection criteria more explicit, not a reason to recommend it universally.

Payload has also changed materially since some early comparisons were written. Current decisions should be based on a tested version of the product, the organisation's editorial and operational needs, and the team that will own it after launch.

The useful question is not whether Payload is a good CMS. It is whether its strengths match the work you need to do and the responsibilities you are prepared to carry.

What Payload is now

Payload describes itself as an open-source Next.js backend. Its configuration is written in TypeScript, and it can generate an administration interface, database schema and migrations, APIs, authentication, access control and file handling from that configuration. It supports official adapters for PostgreSQL, MongoDB and SQLite and can be self-hosted. These details are current in Payload's product overview, database documentation and deployment guidance.

That combination makes Payload more than a simple content repository and different from a page-building SaaS product. It can sit inside a custom application and allow teams to model content, users, permissions and business logic in one owned codebase.

Ownership brings choices. The implementation team must design, test, deploy, secure and operate the resulting application. Open source and deploy-anywhere do not mean infrastructure-free.

Choose Payload when the content model is part of the product

Payload is a strong candidate when the organisation needs structured, related content that goes beyond a conventional set of web pages.

A professional firm might connect people, services, sectors, insights, credentials, locations and regulatory disclosures. A learning product may relate courses, modules, users and progress. A portal may combine client-specific records with managed explanatory content. Payload's code-defined collections, fields and relationships can make those models reviewable and version-controlled.

This is valuable when the model is a genuine differentiator or when several front ends and services need consistent access to it. It is unnecessary complexity when the need is principally to edit a small marketing site with familiar page components.

Ask the delivery team to demonstrate your hardest content relationships in a working prototype. A diagram and a generic product demo will not expose how editors manage real records or how a schema change reaches production.

Choose it when application and content logic belong together

Payload can be attractive for a Next.js application in which managed content, authentication, permissions and custom workflows are closely connected.

Its generated REST and GraphQL APIs and direct server-side API support different integration patterns. Granular access control can be defined at operation, collection and field level, according to Payload's access-control documentation.

That flexibility is useful and consequential. A developer can express sophisticated rules; an error in those rules can expose data or prevent legitimate access. For client portals and sensitive applications, access control needs threat modelling, automated tests, code review and independent security assurance proportionate to the risk. A partner badge is not evidence that those controls are correct.

Integration-heavy projects should also define ownership of failure. If the CMS connects to CRM, identity, compliance and document services, establish which system is authoritative, how retries and reconciliation work, and how teams diagnose a partial outage.

Choose it when you want control of deployment and data architecture

Self-hosting may help an organisation apply its own cloud, network, monitoring and data-management standards. It can support requirements that are awkward in a fixed multi-tenant SaaS offering.

It also transfers operational responsibility. The implementation needs a supported Node and Next.js environment, a database, persistent file storage, email and often a CDN. Payload's production guidance explicitly identifies these surrounding services and advises teams to test access control before deployment.

Before treating self-hosting as a compliance answer, involve security, privacy and infrastructure owners. Establish:

  • where application data, media, backups and logs reside;
  • who patches each component;
  • how secrets and privileged access are managed;
  • what is monitored and who responds;
  • recovery objectives and tested restoration;
  • the upgrade and vulnerability-management process;
  • support arrangements outside working hours;
  • exit and data-export requirements.

Control is useful only if the organisation has the capability to exercise it.

Choose it when sustained development is expected

Payload is code-first. New fields, collections, hooks, permissions and deeper administration changes are made through the codebase and deployment process.

That is a strength for teams that want schema changes reviewed, tested and promoted consistently. It is a mismatch if the operating assumption is that a small marketing team will alter the information architecture indefinitely without developer involvement.

Define the ownership model before procurement. Who reviews upgrades? Who changes schemas? Who supports editors? How quickly can a small request be released? What happens if the current agency relationship ends? If there is no credible answer, the total service is not ready even if the initial build is affordable.

Do not reject it on outdated workflow assumptions

Older Payload comparisons sometimes claim that drafts, versions, scheduled publishing or preview are absent. Current documentation shows configurable versions, drafts, autosave, preview support and scheduled publishing capabilities. See Payload's versions and drafts documentation.

Availability is different from suitability. A feature may require configuration or a front-end implementation to create the workflow editors expect. Multi-stage approval, separation of duties, localisation, campaign staging and audit requirements should be demonstrated end to end.

Use representative editors in evaluation. Give them real tasks: create a service page, reuse an approved biography, preview a scheduled change, correct a mistake, find an older version and request approval. Measure success and assistance rather than asking whether the interface looks intuitive.

When Payload is probably the wrong choice

The need is a straightforward marketing site

If a small team mainly publishes standard pages and articles, a well-supported system with the right workflows may deliver lower cost and less dependency on developers. Architectural possibility has little value if the organisation never uses it.

There is no long-term technical owner

A project team can launch a Payload application and leave the client unable to evolve it. Without internal capability or a funded support partner, routine changes become procurement events. Choose a service whose operating model matches the organisation's real capacity.

The required workflow is already a commodity elsewhere

If complex approvals, translation operations, campaign planning or regulated content governance dominate the requirement, compare the cost and risk of configuring them in Payload with platforms where they are established capabilities. Test both, including editor effort and administration.

The organisation wants a managed service boundary

Some firms need a vendor to own more of the infrastructure, patching and service response. Payload Cloud or a managed implementation may change the equation, but responsibilities still need contractual definition. If the desired boundary is a complete SaaS content service, evaluate products designed around that assumption.

The ecosystem and portability requirements point elsewhere

Skills availability, implementation partners, plugins and proven integrations affect operating risk. Do not speculate about future ecosystem size. Check the people and components available now, the licences involved, their maintenance history and how much custom code would remain if a supplier changed.

Counter the agency incentive

Developers reasonably prefer tools that let them work effectively. Their experience matters because it affects quality and maintainability. Editors, security teams, service owners and finance experience the platform differently.

Require every recommendation to include:

  • the evaluated alternatives;
  • knockout requirements and weighted criteria;
  • a prototype of high-risk journeys;
  • three- to five-year cost assumptions;
  • internal and supplier responsibilities;
  • upgrade, support and exit plans;
  • material risks and mitigations;
  • reasons the recommendation might be wrong.

Ask the agency to explain which work Payload creates as well as which work it removes. Distinction should meet the same standard.

A decision sequence

Start with outcomes and users. Define the client or operational service the platform supports, the editor groups and the decisions they make.

Then model content and integration boundaries. Identify the systems of record, sensitive data, workflow, access needs and likely change frequency.

Prototype the difficult parts in competing options. Include editorial work, permissions, preview, integration failure, deployment and a schema change after launch.

Finally, compare the whole service. Include implementation, hosting, supporting services, monitoring, security assurance, licences, upgrades, editor support, development capacity and exit. Record uncertainty rather than hiding it inside one total.

Payload should win because evidence shows that its control and application model create value worth owning. It should lose when a simpler or more managed service meets the need with less risk.

The product facts in this article were checked against official Payload documentation in August 2026; verify them again at the point of selection.

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.