We adopted Payload CMS in early 2024 after evaluating it against Directus, Strapi, and Sanity for a client project that needed a Node.js-native headless CMS with strong TypeScript support. Six months later, here's our unfiltered assessment.
What Payload does well
TypeScript-first, genuinely
Payload's schema definitions are TypeScript — not YAML with TypeScript wrappers, not code that generates TypeScript types as a side effect. Your content model is TypeScript. The CMS derives everything else — the admin UI, the API response shapes, the query validation — from those types. The development experience this enables is genuinely different from every other CMS we've used. When you rename a field, the TypeScript compiler tells you everywhere in your codebase that breaks. When you add a field, the API response type updates automatically.
The local API
Payload exposes a JavaScript API that lets you query and mutate content programmatically without going through HTTP. For server-side rendering in Next.js or for build-time static generation, this is a significant performance win. Fetching content through REST or GraphQL on the same server as the CMS adds unnecessary latency. The local API eliminates it entirely.
Access control
Payload's access control model is function-based. Each collection, field, and operation can have an access function that receives the request context and returns a boolean. This is more expressive than role-based systems and composes naturally with complex authorization requirements. We've implemented multi-tenant content separation, field-level permissions based on subscription tier, and time-based content embargoes — all without fighting the CMS.
Where Payload struggles
The admin UI is functional, not refined
The admin interface gets the job done, but editors who are accustomed to WordPress or Contentful notice the difference. The richtext editor (Slate by default, Lexical in newer versions) lacks some affordances that non-technical editors expect — drag-and-drop block reordering, visual media management, and inline preview are all more limited than the market leaders.
This is improving rapidly with each release, but if your primary buyers are non-technical editorial teams who will evaluate the CMS themselves, manage their expectations carefully.
Ecosystem maturity
Payload doesn't have a plugin ecosystem equivalent to WordPress or even Strapi. Need a specific integration? You'll build it yourself. For experienced Node.js teams this is fine — you're building custom integrations anyway. For projects that rely on community-maintained plugins for standard functionality, it's a real constraint.
Documentation gaps
The core documentation is good. The edge cases and advanced configurations are often not documented and require reading the source code or asking in the Discord. This is normal for a platform at Payload's stage of maturity, but factor in the learning curve.
When we recommend Payload
- Teams with Node.js/TypeScript expertise building for a Next.js frontend
- Projects with complex content modeling requirements that would be painful in YAML-based schemas
- Multi-tenant SaaS applications that need CMS functionality embedded in the application itself
- Clients with moderate technical sophistication who are comfortable with a less polished admin UI
When we recommend something else
- Non-technical editorial teams who need a best-in-class content editing experience (Contentful, Sanity)
- Projects that need a plugin ecosystem for standard integrations (Strapi, WordPress)
- Teams without TypeScript experience who would be working against the grain of the platform
Overall: Payload is a serious tool for serious teams. Six months in, we're building more projects on it, not fewer. Get in touch if you'd like to discuss whether it's the right fit for your project.
