Next.js + Payload CMS instead of WordPress — when and why
A client comes in with a brief: we want a WordPress site. I ask: why? Because everyone does it that way. That's where the conversation starts.
I sat with that answer for a moment. Not because it's wrong — but because it's automatic. WordPress became the default choice not through quality, but through market inertia. And that's exactly the problem — when someone picks a tool out of habit, they usually don't know what they're getting into.
I started explaining what it would actually mean for their project.
WordPress isn't bad — it's old
I have nothing against WordPress as a project. It's a piece of internet history, an active community, a massive ecosystem. But it's from 2003. The world of websites has changed fundamentally since then — and WordPress still carries many of the architectural decisions from that era.
That doesn't disqualify it outright. But it's worth asking: is a tool built before smartphones, before React, before Core Web Vitals, the optimal choice for a company website in 2025?
Sometimes yes. Often no.
What Next.js + Payload CMS means for a client
I won't explain technically. I'll explain in business terms.
Zero monthly CMS fees. Payload CMS is open-source — you install it on your own server. There's no "pay per editor" model. No invoices for access to your own content. The site management panel is yours forever, with no subscription.
The site works like an application. Next.js generates pages statically or renders them server-side — depending on the need. In practice, this means load times around a second, excellent Core Web Vitals scores, and none of the performance issues that are an everyday reality for WordPress sites loaded with plugins.
Content as data. This is the difference clients don't understand at first, but come to appreciate the most. In Payload CMS, content is structured like a database, not like a blocky text editor. Want to display the same content on your website, in a mobile app, and in an external catalogue? One API, all channels. In WordPress, that would be a lot of plugins and a lot of hoping.
When WordPress makes sense
To be fair — there are situations where WordPress is the better choice.
If a client runs their own blog and wants to install new themes without a developer — WordPress has the UX for that, and it works. If the project needs something very specific from the WooCommerce ecosystem or a particular plugin with no equivalent — there's no point building it from scratch. And if the budget is genuinely small and the site is simple — WordPress on shared hosting is a cheaper start.
But "because everyone does it that way" isn't a sufficient reason for a company that takes its project seriously.
Who will own it in three years
I always ask clients: who will be managing this site in three years?
That question changes the conversation. It's not about technology — it's about whether in three years you'll be on a platform that decides what's possible for you, or on a tool that's yours and grows with your needs.
If you have a project and are thinking about stack choice — let's talk.