PayloadCMS: Why I Chose It Over WordPress for Client Projects

I’ve built a lot of WordPress sites. For years, it was my default recommendation for any client who needed a content-managed website. It’s the most popular CMS on the planet for good reason — it works, it’s mature, and clients can manage their own content without calling me every time they want to update a page.

But over the past year, I’ve shifted the majority of my new client projects to Payload CMS. This wasn’t a snap decision or a case of chasing shiny new technology. It came from genuine frustration with WordPress’s limitations and a growing appreciation for what Payload brings to the table.

Here’s the full story — including the things I still miss about WordPress.

The WordPress Problems That Pushed Me Away

Plugin Dependency Creates Fragility

Every WordPress site I’ve built has relied on a stack of plugins. Even a simple brochure site typically needs plugins for SEO, security, caching, contact forms, and custom fields. Each plugin is a dependency you can’t fully control.

I’ve had client sites break because a plugin update conflicted with another plugin. I’ve had plugins abandoned by their developers, leaving security holes. I’ve had premium plugins change their pricing models, forcing clients to pay more or find alternatives. Each of these situations means unplanned work and cost for the client.

With Payload, the functionality I need is either built in or implemented through custom code that I control entirely. There’s no third-party dependency risk for core functionality.

Performance Requires Constant Effort

Making WordPress fast requires active work — caching plugins, image optimisation plugins, database cleanup plugins, CDN configuration. You’re adding complexity to solve a performance problem that exists because of the platform’s architecture.

WordPress generates pages dynamically on every request (unless cached), queries a MySQL database multiple times per page load, and loads whatever CSS and JavaScript its active plugins and theme require. Even with good caching, the underlying architecture means you’re always fighting for performance rather than starting from a fast baseline.

Payload, running inside a Next.js application, serves pages that are statically generated or server-rendered at the edge. The performance baseline is excellent without any optimisation effort.

The Block Editor Is Polarising

WordPress’s Gutenberg block editor is powerful, but it’s also divisive. Some clients love it; many find it confusing. The interface tries to be both a content editor and a page builder, and it doesn’t excel at either.

I’ve spent hours training clients on Gutenberg, only to receive panicked emails about accidentally deleting a block or not being able to replicate a layout. The editing experience is better than the old Classic Editor for structured content, but it’s worse for simple “I just want to write a paragraph” scenarios.

Security Is a Constant Concern

WordPress powers over 40% of the web, which makes it the biggest target for automated attacks. Every WordPress site I manage needs regular security updates, monitoring, and hardening. It’s not that WordPress is inherently insecure — it’s that its popularity and plugin ecosystem create a large attack surface.

With Payload, the attack surface is dramatically smaller. There’s no public-facing admin URL that bots hammer with login attempts. The admin panel can be locked down to specific IP addresses or placed behind authentication layers. And because there’s no plugin ecosystem to worry about, there are fewer potential vulnerabilities.

What Payload CMS Offers Instead

Code-First Configuration

Payload’s content models are defined in TypeScript configuration files. This might sound like a disadvantage if you’re used to WordPress’s visual approach, but it’s transformative for reliability.

When I define a content type in Payload — say, a “Project” with fields for title, description, images, and client name — that definition lives in version control. I can review changes in pull requests, roll back mistakes, and deploy the same content structure to development, staging, and production environments consistently.

In WordPress, content types created through plugins exist in the database. Moving them between environments requires exports, imports, and prayer. I’ve lost count of the times a WordPress migration has gone sideways because a custom field group didn’t transfer correctly.

TypeScript Throughout

This is the single biggest technical advantage for me. Payload generates TypeScript types from your content schema automatically. When I query content in my frontend code, my editor knows exactly what fields are available, what types they are, and flags errors if I reference something that doesn’t exist.

When a client asks me to add a field to their content type, I add it to the Payload config, and TypeScript immediately tells me everywhere in the frontend that needs updating. With WordPress, this kind of change requires manual checking across template files and hoping you haven’t missed anything.

The Admin Panel Is Excellent

Payload’s admin panel is clean, fast, and focused. Content editors see exactly the fields they need — nothing more, nothing less. There’s no sidebar full of meta boxes, no confusing distinction between posts and pages, no Gutenberg blocks to wrestle with.

For clients who just need to update text, swap images, and publish new content, Payload’s admin is simpler and more intuitive than WordPress. The learning curve is shorter because there’s less to learn.

Access Control That Actually Works

WordPress’s user role system (Administrator, Editor, Author, Contributor, Subscriber) is basic. If you need a user who can edit pages but not posts, or who can publish blog articles but not change site settings, you need a plugin like User Role Editor.

Payload’s access control is defined in code and works at the field level. I can create a role where marketing staff can edit the promotional banner text but can’t touch the site footer. I can make certain fields visible only to administrators. I can restrict access based on any criteria I need. This granularity is built in, not bolted on.

It Runs Inside Your Application

Rather than being a separate system that your website queries, Payload runs inside your Next.js application. This means content queries are local function calls, not HTTP API requests. It’s faster, simpler to deploy, and easier to reason about.

One codebase. One deployment. One database. Compare this to a WordPress setup where you have the WordPress installation, possibly a separate frontend application, database servers, and the challenge of keeping everything in sync.

What I Genuinely Miss About WordPress

I’m not going to pretend Payload is better at everything. WordPress has legitimate advantages.

The Plugin Ecosystem

When a client needs a specific integration — say, a booking calendar, a membership system, or a complex form builder — WordPress likely has a plugin that does it. With Payload, I’m building these features custom. The result is usually better tailored to the client’s needs, but it takes more development time.

The Community

WordPress has twenty years of community knowledge. Every problem has been solved, documented, and discussed somewhere. Payload’s community is active and helpful, but it’s smaller. Sometimes I need to figure things out from source code rather than finding a tutorial.

Non-Developer Accessibility

A reasonably tech-savvy business owner can set up a basic WordPress site themselves. That’s not possible with Payload — it requires a developer for setup and any structural changes. This limits its audience to businesses that have developer resources.

Hosting Simplicity

WordPress hosting is ubiquitous and cheap. Nearly every hosting company offers one-click WordPress installation. Payload requires Node.js hosting, which is less common and slightly more involved to set up, though providers like Railway, Render, and Vercel make this increasingly straightforward.

When I Still Recommend WordPress

Despite my preference for Payload, there are situations where WordPress is the right call.

Very tight budgets with no ongoing developer relationship. If a client needs a basic website and won’t have access to a developer for maintenance, WordPress with a quality theme is more practical.

Complex existing WordPress infrastructure. If a client has a WordPress site with years of content, custom integrations, and workflows built around the WordPress admin, the migration cost may not be justified.

Specific plugin requirements. If a project genuinely needs functionality that only exists as a WordPress plugin and would be expensive to build custom, WordPress is the pragmatic choice.

The Decision Framework

When evaluating WordPress vs Payload for a new project, I consider three factors.

Does the client have ongoing developer access? If yes, Payload’s advantages in type safety, performance, and security make it the better long-term investment. If no, WordPress might be more practical.

How important is performance? For businesses where site speed directly affects revenue (e-commerce, lead generation, local services), Payload’s performance advantage matters. For a simple informational site with low traffic, it matters less.

What’s the expected lifespan of the site? For a site that’ll be used for five or more years, Payload’s lower maintenance burden and reduced security risk save money over time. For a short-term project, WordPress’s faster initial setup wins.

Moving Forward

If you’re currently on WordPress and curious about whether Payload CMS would be a better fit, let’s have a conversation. I can assess your current setup, understand your needs, and give you an honest recommendation. Sometimes WordPress is still the answer — and I’ll tell you that if it is.