Why I Pick Payload CMS for Most Client Builds

When someone asks me to build them a website, the conversation almost always lands on the same three questions, even if they do not realise it yet:

Will it be fast?
Will I own it?
What is it actually going to cost me over the next five years?

The first two are easy. The third is the one that quietly decides everything else, and it is the one most people find out about too late.

The four options most people weigh

Once you get past the noise, there are really only four practical paths for a marketing site that needs a blog, some case studies, and the occasional landing page refresh:

A fully custom build — Next.js with a Postgres database, no off-the-shelf CMS
WordPress — the default, the one most non-technical buyers reach for first
A static site — markdown files in a Git repo, deployed to a content delivery network
A headless CMS — Payload, Sanity, Contentful, Strapi, the modern alternatives

Each one has a real reason to exist. None of them is the best in the abstract. Here is how I think about them when I am sitting across from a client.

Custom build: the most control, the most friction

Building a marketing site in pure Next.js and Postgres gives you everything a senior engineer wants: total control over how things render, total control over the data shape, no vendor in the middle, no per-seat pricing, no plugin marketplace.

What you give up is everything else.

Every non-engineer on the client's team becomes a bottleneck. Want to publish a case study? Open a pull request. Want to fix a typo on the home page? Open a pull request. Want to A/B test a hero headline? Open a pull request. "Owning your content" turns out to mean "owning your deployment pipeline," which in turn means your developer is now a permanent dependency on every small change.

For a startup that ships product pages weekly, this is fine, because engineers are doing the writing anyway. For a regional operator who wants their marketing manager to update a landing page on a Tuesday afternoon, it is pure friction.

My take: pick this when the content changes rarely and the team writing it is technical. Otherwise it ages badly.

WordPress: cheap to start, expensive to live with

WordPress powers a huge share of the web for a reason. The admin is fine. Plugins solve every problem you can name. Hosting is cheap. The install takes an afternoon.

The yearly cost, when you actually add it up, is not cheap at all:

Managed hosting runs anywhere from a few hundred to over a thousand dollars a year
Premium plugins for forms, SEO, caching, and security add another few hundred on top
Cleaning up after a security incident costs anywhere from a few hundred to several thousand dollars every time it happens, and it will happen
Developer time to keep plugins, themes, and PHP versions current runs into thousands a year for any site that earns real revenue
Backups, staging, and uptime monitoring add another few hundred

For a serious business site, that is somewhere between five and twenty thousand dollars a year in recurring cost before you have written a single new feature. The data is also locked inside a WordPress database that does not talk to anything else you build, so every new thing you want to do costs more.

Then there is the maintenance tax that never makes it onto a quote: every WordPress site has to be kept current with security patches, PHP versions, and plugin updates, indefinitely. Skip that work and the next breach finds you. Do that work and you have a small annual retainer that never ends.

My take: pick this when the client explicitly wants it, has an internal team that already runs it, or has a regulatory reason to stay on PHP and MySQL.

Static site: zero recurring cost, zero flexibility

A few markdown files in a Git repo, deployed to a CDN. Fast, free, no database, no admin panel, nothing to log into. This is roughly what I use for my own site when I want to write something and forget about it.

What it does not do:

The client cannot publish. Period. Every change is a developer change.
Search, tag pages, related posts, author pages — all of it is custom code you write and own forever.
The day the client asks "can someone on the team edit this," you either rebuild the whole thing or bolt on a CMS anyway, which defeats the point.

My take: pick this for personal sites, documentation, small marketing pages that almost never change, and any project where the team is one or two engineers who do not mind owning the content forever.

Payload: where I land most of the time

Payload is a headless CMS that lives inside the Next.js app. Same repository, same database, same deployment. The admin panel is part of the build, and it is the part I am most often explaining to clients who have never seen it.

The things that matter to me as the person building it:

The database is ours. Not Payload's, not a third party's, ours. Posts can be joined with anything else in the system and shipped through the same API as everything else.
The schema is code. Every collection is a TypeScript file in the repo. When the schema changes, the change goes through a pull request.
The auth is ours. No SaaS login to maintain, no per-seat pricing to renegotiate, no vendor to email when something breaks.
The deploy is the same one. It runs on the same Vercel project as the rest of the site. One pipeline, one place to look when something is wrong.

The things that matter to the client:

A polished admin panel they can log into from a browser
Rich text, image uploads, drafts, scheduled publishing, version history, all of it working out of the box
No monthly software bill. The CMS is part of what was built, not a separate subscription that quietly shows up every January

The thing that really seals it for me is the recurring cost conversation. Once the build is done, the CMS is part of the codebase. There is no second bill. There is no plugin marketplace that adds up over time. There is no SaaS vendor whose pricing page I have to explain to a client every year. For someone who expects to pay a one-time build fee and then a small retainer for ongoing work, this is a much cleaner conversation than "and by the way, here is your fifteen thousand dollars a year in WordPress hosting and plugins for the next decade."

When I would still pick something else

I am not married to Payload. There are a few cases where I would go a different way without thinking twice:

A single-page brochure site that changes once a year. Static is cheaper and faster and there is no point adding a CMS.
A large editorial team that needs role-based workflows, multi-stage approvals, and content scheduling across time zones. That is a real enterprise CMS, and I would rather hand it to a team that does nothing else.
A business that already runs WordPress well, with an internal team that knows it, twelve years of muscle memory, and a plugin stack that works. The migration cost is rarely worth it.
A small, technical team that genuinely wants every line of content version-controlled and reviewed in pull requests. Pure Git-based content is the right answer for them.

The argument I keep coming back to

The thing I like most about Payload is not the admin panel. It is that a project can start with a single collection — say, a blog — and quietly grow a careers page, a case studies page, a customer portal, and a few forms later, all inside the same repository, the same database, the same deploy.

A client who started with "just a marketing site" six months ago is now asking for a customer portal? Payload collections sit next to the regular Next.js routes and the regular Postgres tables. Nothing is bolted on, nothing is held together with a different vendor's API.

That is the real reason I keep reaching for it. It grows with the project, and it does not punish you for growing.

If you are about to pay someone to build you a site and the conversation is going to include the words "monthly hosting fee" or "annual plugin renewal," push back. There is almost certainly a cheaper, cleaner answer.