Headless CMS: why we build with Payload

A headless CMS is usually sold on how fast it makes the website for visitors. For the person updating the website every week, that matters less than an admin interface built as an afterthought, with the fields the developer needed rather than the ones the editor needs. That’s where a CMS proves its worth.

We’ve been building websites in WordPress for many years, alongside working with headless technologies such as Next.js and headless WordPress. Along the way, we’ve compared newer systems with established platforms — WordPress, Drupal and Optimizely — by asking two questions: how fast is the website for visitors, and what is it like to work with every day? Payload has delivered the best answer to both, and we now use it to build both pigment.se and our clients’ websites.

First, what is a headless CMS?

A headless CMS is a content management system that separates the editor’s tools from the website visitors see. Content is retrieved through an API (an interface that lets programs fetch data from one another), while the website itself is built using a technology such as Next.js. Because the website doesn’t need to query the database for every page view, it can display cached content and move between pages without reloading everything. That’s where the speed comes from.

Why isn’t a fast website enough?

For a long time now, almost any headless technology has been capable of delivering speed, with ready-made code packages as a starting point. The hard part comes after launch, when editors need to publish news, replace images and build new landing pages. If the admin interface is built around the data model rather than their work, every change becomes a request to the agency. Speed for visitors then comes at the cost of slower work inside the organisation.

That’s why, for us, three things in the admin interface matter just as much as performance: editors must be able to build pages themselves using ready-made blocks, preview exactly what will be published, and manage images and languages without asking for help. If any of these is missing, the system is fast for everyone except the person who uses it most.

What does Payload do differently?

Payload is an open-source CMS written in TypeScript. Since version 3, it installs directly into the same Next.js application as the website. The admin interface and website therefore share code and a data model, so changes to the content structure take effect in both places at once. This also makes previews accurate: as editors write, they see the page rendered with the same code visitors will see.

The data model — the available page types, fields and blocks — is defined through configuration in code rather than assembled in an interface. It is therefore version-controlled and reviewed just like the rest of the project. Much of what requires custom code in older systems, such as language management, image cropping and permissions, is handled through settings. That leaves developers free to focus on what is specific to the client: integrations, workflows and the logic that supports their organisation.

For editors, it feels familiar. Anyone who has worked in WordPress will recognise the list of pages, the form for each page and the blocks arranged in sequence. Here, though, every block and field is built for that particular website, so there are no settings editors have to learn to avoid. Images are cropped around a focal point set by the editor, keeping the subject in the right place across all formats. Every save creates a version that can be compared with others and restored.

How has it worked in practice?

One example is fuzed.com, a multilingual website with extensive content and demanding performance and media management requirements. We were able to set up an initial version early, let the client give feedback on something that actually worked, and then refine the content model and design in parallel. The client builds new pages with new combinations of blocks directly in the admin interface, so moving a button or adding a section doesn’t require a developer.

Pigment.se is built in Payload in the same way. We’ve also built a custom plugin that translates Swedish text into English when it is saved. This shows another side of the system: missing functionality can be built into the admin interface rather than added as a separate tool alongside it.

When is Payload not the right choice?

Payload requires a developer to take responsibility for the content model, because new block types and fields are written in code. If you want to install a ready-made theme and add functionality yourself using plugins, WordPress and its extensive plugin library will serve you better. The same applies to a small website with just a few pages, where the performance gains rarely outweigh the cost of developing and running a bespoke solution.

What if the company behind it disappears?

That’s a fair question about a relatively new system. Payload is open source under the MIT licence, which allows the code to be freely used, modified and developed further. The code will therefore remain available regardless of what happens to the company. Payload has been owned by Figma since June 2025. This has given the project an owner with substantial resources, but it also makes it worth watching whether Payload retains the same priority as a standalone CMS as its ties to Figma grow.

The system itself is free to install and run on your own server. The costs are hosting and development, just as they are with WordPress.