Why I Use Payload CMS for Every Project Now

I picked up Payload CMS about a year ago, mostly because I needed something that would let me define my own data structure without fighting the tool. I've shipped three or four projects on it now — a film production SaaS, a fintech CRM, this blog. At this point I'd reach for it before almost anything else.

Here's my honest take on it.

What actually drew me in

The first thing that clicked was that Payload's config is just TypeScript. Your collections, your fields, your access control — all of it lives in code, all of it is type-safe, and none of it requires a separate admin dashboard login to change the structure.

That might sound like a small thing. It isn't. Being able to define a collection and immediately have type-safe queries in the same codebase removes an entire category of bugs. You stop wondering whether the field is called coverImage or cover_image. The compiler knows. You know.

It's not headless-CMS-shaped

Most headless CMSes are built around the idea that content editors are the primary users. The developer API is secondary — something you bolt onto the content management layer.

Payload is the other way around. The developer experience is the product. The admin UI is generated from your config, which means it always matches your data model instead of you having to maintain them in sync. That's a real difference in practice.

Where it earns its keep

Next.js projects. Payload is built for this. Local API access means no HTTP overhead in server components, and the Next.js integration is properly maintained rather than being an afterthought.

Projects that need custom logic. Hooks — beforeChange, afterRead, and so on — are just functions. You can run anything in them. I've used them for sending emails, updating related collections, syncing data to external APIs. No plugin marketplace needed, just code.

Projects where access control matters. The access control layer is field-level and function-based. You can write arbitrary logic. For the fintech CRM I built, this mattered a lot — different user roles needed different data visibility, and I could express all of it in the config without hacks.

Where it's harder

The learning curve is steeper than something like Contentful if you've never touched a framework-style CMS. There's more setup upfront. If you just need a quick content layer for a marketing site with no custom logic, there are faster options.

The ecosystem is also smaller. You won't find as many community plugins or third-party integrations compared to more established CMS options. You end up building more yourself, which I mostly don't mind, but it's worth knowing.

The MCP server angle

I wrote about this in a previous post — I gave my Payload-powered site an MCP server. This is possible because Payload exposes a clean local API that maps directly to your collections. Once I had that, I could let Claude read, create, and update posts through tool calls. That's not a Payload-specific feature, but Payload's structure made it straightforward to build on top of.

Should you use it?

If you're a developer building something custom — not a "spin up a blog in an afternoon" situation — and you want full control without a managed service, yes. The upfront investment pays off quickly once you stop maintaining two separate representations of the same data model.

If you're setting something up for a non-technical client who needs a polished editor experience out of the box, the tradeoffs are different. It's worth considering what they'll actually be touching day-to-day.

I've been happy with it. The fact that I keep reaching for it on new projects probably says more than anything else.