We've used WordPress, Sanity, Strapi, Contentful, and Directus across dozens of client projects. When Payload CMS 2.0 shipped — and especially with 3.0's Next.js integration — we found what we'd been looking for: a CMS that thinks like a developer.
Code-First Configuration
Payload collections are defined in TypeScript files, not through a GUI. This means our content schema lives in version control, gets reviewed in pull requests, and deploys through CI/CD like any other code change. No more "someone changed a field in the admin panel and broke the frontend" surprises.
It Lives Inside Next.js
Payload 3.0 runs as a Next.js plugin. The admin panel, the API, and the frontend share a single deployment. There's no separate CMS server to manage, no CORS configuration, no API gateway. When we call payload.find() in a Server Component, it's a direct database query — no HTTP overhead, no serialization round-trip.
Full TypeScript Coverage
Every collection generates TypeScript types automatically. When we add a field to a collection config, the generated types update, and our IDE immediately flags any frontend code that needs to change. This catches bugs at build time that would otherwise surface in production with a traditional headless CMS.
Access Control That Actually Works
Payload's access control system is function-based. Instead of role strings and permission matrices, you write TypeScript functions that return booleans. Need to restrict blog editing to the author? It's a three-line function. Need field-level access control? Same pattern. This flexibility is something we consistently struggled with in other CMS platforms.
Self-Hosted, No Vendor Lock-In
Unlike Contentful or Sanity, Payload runs on your own infrastructure. The data lives in your MongoDB or Postgres instance. There are no per-seat costs that balloon as your client's team grows, no API rate limits, and no surprise pricing changes. For agencies delivering projects to clients, this predictability is invaluable.
The Rich Text Story
Payload's Lexical editor is extensible and stores content as a structured JSON tree — not HTML strings. This means we can render the same content across web, mobile, and email without parsing HTML. Custom blocks, inline embeds, and content relationships all work within the editor natively.
Payload isn't perfect — the documentation could be deeper, and the plugin ecosystem is still growing. But for teams that value code-first workflows and TypeScript-native tooling, it's the best CMS we've worked with.
