Payload CMS — what it is like to run a company site on it

Most articles about Payload CMS are rewritten documentation. This one is different for one reason: the site you are reading right now runs on Payload — the admin panel it was written in, the calculators in our tools section, and its four language versions included.

So this is about what follows from working on it: what turned out better than expected, what cost us weeks, and who we would not recommend it to.

How Payload differs from the CMS you know: "code-first"

In WordPress and in Strapi, content structure is clicked together in a panel. You add a "Price" field, pick a type, save it — and it shows up in the form. Convenient, until someone names a field "Price " with a trailing space, or deletes it on a Friday evening.

Payload works the other way round. Structure is code: a developer describes a collection and its fields in a file, and the panel is a reflection of that code. You cannot add a field from the panel, because nobody designed the panel by hand — it is generated from the code.

For a company, in order of importance:

• Content structure passes through the same gates as the rest of the software — code review, tests, change history. It is on record who added a field, when, and why.
• There is no "a typo in a field name took down the homepage" class of bug, because field names are types, and a mismatch is caught before deployment, not by a reader.
• Editors lose the ability to change structure on their own. A new field, or a new kind of section, becomes a developer's task. That is a real cost, and we come back to it below.

On our own site, that "structure as code" has produced 28,010 lines of generated type definitions — a file nobody writes by hand, one the whole application depends on, and a physical measure of how much structure a company site carries.

What version 3 changed: one application instead of two

This is the change that matters most in a conversation with a CTO, and gets lost in the marketing.

Before, a headless CMS was a separate server: standing next to the site, with its own deployment, hosting and upkeep. Since version 3, Payload installs into a Next.js application — the vendor's own documentation puts it plainly: "Add Payload to a new or existing Next.js app" (payloadcms.com).

What that means for the bill:

• One deployment instead of two. The panel and the site are the same application, so there are no two environments to stand up, monitor and update.
• One hosting bill. The separate backend server disappears, and with it a separate line in the infrastructure budget.
• Less administrative work. No two deployment pipelines to keep in sync, no two places where versions drift apart.

For a company without its own maintenance team, that is the difference between "we need someone in DevOps" and "a developer who knows Next.js is enough."

What this looks like on our own site — in numbers

We counted all of the following from this site's own repository on 11 September 2026:

The "parent post" column is not decoration — the whole hierarchy of the section, from topic hub down to a single article, is a relationship in the data. That lets the URL, the breadcrumbs and the related-posts list all come from one place, instead of being typed in three times by hand.

This one screen shows four things at once. Tabs split fields into groups, so an editor does not scroll past a hundred fields to reach the title. The "— pl" tag next to a field means language is a property of the field, not a separate page: the same data has four values, not four copies. The "Banner" block is one of forty building blocks that make up the content. And the "Translate" button triggers machine translation into the other three languages — a feature that does not ship in the box; we built it ourselves because the panel is part of our own application.

This stopped being just a content system a while ago

The most interesting thing in that table is not the articles — it is what grew up around them. Of the thirty-nine collections, a good share have nothing to do with content:

• CRM — companies, contacts, customers and the relationships between them;
• mailbox and calendar — mail accounts, messages and events pulled in from outside, so the history of a customer relationship sits in one place;
• meetings — meeting types, available slots, bookings;
• leads — submissions from the calculators, tool results, brief-wizard sessions;
• campaign data — ad clicks and the search terms behind them;
• performance measurements — Core Web Vitals from real users, which we use further down in this article.

Every one of those is the same structure as an article: fields in code, its own permissions, its own API. No separate system to buy, no four subscriptions to wire together — after two years, that is the argument that convinces us most.

What the same thing would look like on WordPress

It can be done. The question is what the bill would be made of:

We can price part of this stack: a popular page builder renews annually somewhere between €228 and €540, depending on plan (our SaaS pricing survey, captured 26 August 2026). WordPress technical care alone costs PLN 300–900 a month on the Polish market in typical packages, plus PLN 70–250 an hour for additional work (our own market research, captured 25–26 August 2026). On top sit licences for whichever other plugins from the table you actually need.

Payload carries no licence fee, but has its own cost — the developer, covered below. The difference is not that it is cheaper. It is where the cost sits: there, in subscriptions and renewals; here, in your own code.

Performance: our own data, not a benchmark

This is the part you do not have to take on faith — because we measure it on ourselves, from real visitors.

Our database holds a collection of Core Web Vitals measurements sent from the browsers of people visiting this site. Between 26 July and 11 September 2026 we collected 10,003 measurements. Results at the 75th percentile — the same way Google counts them:

• LCP 1,444 ms against a 2,500 ms threshold — 88% of measurements in the "good" band (n = 2,016)
• INP 88 ms against a 200 ms threshold — 96% in the "good" band (n = 972)
• CLS 0.00 against a 0.1 threshold — 87% in the "good" band (n = 1,882)

Split by device, LCP runs 1,636 ms on desktop and 1,120 ms on phones — faster on phones, which is the opposite of what most people expect, and comes down to smaller images served to smaller screens.

What these numbers do not say. We are not comparing them to WordPress: we run no equivalent site to measure the same way, and the public comparisons in circulation contradict each other and render their data in the browser, so we cannot cite them honestly. What they do say is enough: this stack keeps all three metrics in the "good" band, on data from real people, not a one-off lab test.

Mechanically, the edge comes from the page being assembled on the server and sent as finished HTML, with no theme layer or stack of plugins each adding their own scripts. How to measure this on your own site so the result means something, we cover in our article on testing a website.

What works better than we expected

Version history nobody has to remember to keep. Every save creates a version, and a draft is distinguishable from a published one. A fix that broke something rolls back with one click, without asking anyone for a backup.

The panel is part of the application, so it can be extended. A custom button, field or validation rule is code in the same repository, not a third-party plugin that might stop being maintained. Our machine translation, the short links generated on publish, and the automatic social-media images all came from exactly that.

Types instead of documentation. Since fields are code, the rest of the application knows everything about them: a typo in a field name fails to compile, it does not show up as a blank spot on the page.

Language as a property of a field, not a separate page. That sounds like a detail until you run a site in four languages. Classically, four languages are four separate pages maintained in parallel, drifting apart after the first fix made in only one. Here an article is one document, and language is a dimension of a field: an image or category change touches every version, a sentence change only the one you typed it into. Relationships between articles are shared too, so a link set once works in every language.

Permissions that can be described precisely. Since access is code, "this role only sees its own posts, that one can publish, this one never touches customer data" holds everywhere — in the API too, not just how the panel looks. On WordPress, that level of control usually means another plugin.

What cost us time

Honestly, because this is the part that reviews leave out.

A conflict with Next.js 16's caching mechanism. The new pre-rendering model — a static shell served instantly, dynamic fragments streamed in behind it — needs a global flag in the configuration, and the Payload panel does not work with that flag on: it relies on the current time and on dynamic data access, and the flag is global or nothing, never per route. The practical conclusion, which cost us time to even recognise: the panel and the site then have to be two separate deployments, undoing part of the "one application" benefit above — plan for that at the start, not mid-project. More on the mechanism itself in our piece on Next.js and React.

The editorial team's learning curve is real, and it runs differently than we expected. It is not about operating the panel — that part is simpler than WordPress. It is a clash of habits: on WordPress, someone in marketing needing a new SEO field installed a plugin and had it in fifteen minutes; here, they ask a developer and wait for a release. The first weeks after a switch are not about learning a tool — they are learning a new division of labour, worth naming to the team up front.

Content structure needs upfront decisions. Since fields are code, adding a twenty-first section type is a development task — and on a project where nobody thought through what would be needed, that backlog grows faster than the budget.

What moving from an existing system looks like

The most common question after deciding is what happens to existing content. The order that worked for us, and that we suggest to clients:

Structure first, not data. Before anyone exports a single entry, someone has to describe in code what content types exist and what they consist of. This is where it turns out "article" in the old system carries a field nobody has touched in two years, and three fields that mean the same thing.

Then migrate in batches, not overnight. One content type first, checked on a dozen entries, only then the rest. URLs move with the content — and a changed one needs a redirect issued before the old one disappears, not after.

Editorial training comes last. The panel is simpler than WordPress, so training takes less time than everyone assumes. The harder part is the division-of-labour change described above — worth a dedicated conversation, not a slide in a post-launch deck.

What never carries over: plugins. Everything a plugin did in the old system — forms, galleries, SEO mechanics — is now work to build or replace with a service. That is the single largest line item in a migration quote, and the one that can tip it over.

Database: MongoDB or Postgres — and why that is a security question

Payload runs on MongoDB and on Postgres — in the vendor's own documentation: "Direct DB access and ownership with migrations, transactions, and proper indexing across MongoDB and Postgres."

That is an organisational choice, not a technical one. In larger companies the database is decided by IT or security, not the project team — procedures sometimes written for relational databases only, so MongoDB can stall approval for reasons that have nothing to do with merit.

Running the same system on Postgres is therefore a pass, not a preference — the first question in any organisation with a formal approval process.

Data sovereignty: where your content physically sits

Subscription systems — Contentful, Sanity — hold content on their own infrastructure: an advantage for most, disqualifying for some.

Financial services, healthcare, public procurement, defence: requirements on data location sometimes rule out someone else's cloud outright. Payload is open-source software you run on your own infrastructure, so "where does the data live" has an answer you supply, not one your vendor supplies — the same split we cover more broadly in our piece on headless architecture: the subscription model takes maintenance off your hands and hands over control with it; self-hosting does the opposite.

Payload, Strapi, Contentful, Sanity — split by philosophy, not by price list

"Best headless CMS" rankings are not useful, because these systems are not competing on the same axis. What differs is who gets to change the content structure:

We deliberately do not quote prices for these systems: we hold none in our own dataset, and a competitor's price list without a capture date goes stale faster than this article. If you are comparing costs, pull them from the vendors' own sites on the day you decide, and treat them as an order of magnitude — subscription software moves prices and limits several times a year.

Who we would not recommend Payload to

A company with no one technical, and no wish to have anyone — in-house or on the vendor's side. Payload needs someone to maintain it, though not necessarily in your office. Three setups work in practice: an in-house developer, an agency on a standing contract, or us. One does not: a system built once by someone who then disappeared, which stands until the first change nobody can make in the panel, and turns into something everyone is afraid to touch.

That is not a reason to rule out headless — it is a line item to name in the budget before choosing a system, not after.

A team that wants to assemble pages by dragging elements around. Payload gives you pre-built blocks, not the freedom to place anything anywhere. If marketing expects that, they will be frustrated — rightly so.

A project whose value is in plugins. A shop, a newsletter, bookings, an online course — off-the-shelf plugins in the WordPress world, work to be done here. Sometimes worth it, sometimes absurdly expensive.

Who we would recommend it to: a company building or running a Next.js application, needing a few locales or channels for the same content, wanting to keep data on its own infrastructure — with a settled maintenance path, in-house or with a vendor.

What it costs

Licence: zero. Payload is open-source software; there is no fee for using it and none per editor.

The cost sits in two other places. Infrastructure — server and database, priced like any application hosting; we break that down in choosing hosting. And developer time, because every structural change or new section type is a task someone has to do. We do not invent market rates — the medians for the Polish market are in our pricing research, and you can price your own case in our calculator.

The thing worth costing out before the decision, not after: how many section types you get to start with, and what happens once you need one more. That is the one line in this bill that tends to catch people out.

Five questions before you decide

1. Who on our side will be able to add a new kind of section, and how fast? If the answer is "nobody in-house," that is an answer about the system, not about the team.
2. How many section types do we get at the start? That number decides how often you will be back with your vendor over the next year.
3. Which database will this run on, and will it clear our approval process? A question for IT, not for the agency.
4. Where does the content physically sit, and who has access to it? If you have regulatory requirements, this is the first question, not the last.
5. What happens if we part ways with our vendor? Repository, documentation, infrastructure access — written into the contract, not promised in a meeting.

Where these numbers come from

• Numbers about our own site — counted from this site's repository on 11 September 2026: 39 collections, 9 globals, 40 content blocks, 22 hero variants, 4 locales, 10 calculator configs, 28,010 lines of generated type definitions.
• Screenshots — this site's own admin panel, run on a local environment, September 2026.
• Installing into a Next.js app, and support for MongoDB and Postgres — Payload CMS documentation, checked at the source on 11 September 2026.
• This site's Core Web Vitals — the web-vitals collection in our own database, 10,003 measurements from real users collected between 26 July and 11 September 2026; values at the 75th percentile, thresholds per the Core Web Vitals documentation.
• The page builder's renewal price — our own SaaS pricing survey, price as published by the vendor and captured 26 August 2026.
• The conflict between the admin panel and Next.js 16's global cache flag — our own deployment experience, not documentation from either project.
• Payload Cloud, Contentful and Sanity pricing — deliberately absent, as explained above.
• WordPress technical-care rates (PLN 300–900 a month, PLN 70–250 an hour) — our own research into the Polish market, captured 25–26 August 2026.