Payload CMS vs WordPress: A Practical Guide for NZ and AU Businesses

If you run a small business in New Zealand or Australia and you need a website your own staff can edit, you will usually hear one name first: WordPress. Payload CMS is a newer option, built for developers making custom sites. This guide explains what Payload is, how it differs from WordPress, when each one makes sense, and what went wrong and right when we ran Payload in production.

We build with Payload, so we have a view. We will say where WordPress is the better choice, too.

Payload describes itself in its documentation as "the Next.js fullstack framework". You write a configuration file describing your content, and Payload gives you an admin panel, a database layer, and REST and GraphQL APIs from it. It is open source (the GitHub repository shows the MIT licence) and written in TypeScript. It works with MongoDB and Postgres.

"Headless CMS" means the place where people edit content is separate from the website visitors see. Payload can be used that way, and its own repository says it can also be used "for building powerful applications". For a small business the practical meaning is simple: staff log in to a tidy admin screen, and the website is a normal Next.js site that reads what they wrote.

WordPress is open source software built on PHP and MariaDB, licensed under the GPLv2, according to wordpress.org. Its own About page calls it "the platform of choice for millions of sites across the web". That reach is a real advantage: almost every web developer has met it, and hosting for it is easy to find.

• What it is built on: Payload is a TypeScript framework that sits inside a Next.js project, so the admin panel and the website live in the same codebase. WordPress is a PHP application.
• You shape the admin: Payload builds the editing screens from the content you define, so a "Services" entry can have exactly the fields you want and nothing else. That keeps the screen simple for non-technical staff.
• Who it suits: WordPress suits people who want to assemble a site themselves from a large, familiar ecosystem. Payload suits sites where a developer is involved and the content has a specific shape.
• Hosting: Payload says you can deploy it anywhere. On serverless hosts its docs recommend a cloud storage adapter for uploads, because uploads through the server are limited (the docs note a 4.5MB limit on Vercel).

• You want to build and change the site yourself, with no developer, and a standard brochure layout is enough.
• You already have a WordPress site that works and nobody is complaining about it. A rebuild has a cost, and "newer" is not a reason on its own.
• Your site depends on a specific WordPress feature you rely on every day and do not want to rebuild.

• The site is part of a Next.js application anyway, such as a booking flow, a dashboard or a customer portal, and you would rather have one project than two.
• Your content has a clear structure (services, team members, opening hours, product specs) and you want staff to fill in fields rather than lay out pages.
• You want a short, controlled list of things staff can change, so they cannot break the layout.
• You want to own the code and the data, and deploy it where you choose.

We cover the wider question of a custom Next.js build versus WordPress in Next.js vs WordPress for NZ business websites.

We built and run a Payload site for a community organisation. Volunteers, not developers, edit the content. It uses Payload 3 on Next.js, MongoDB for the content and an S3-compatible storage bucket (Cloudflare R2) for images. Three things we learned are worth passing on.

Payload uses sharp, a native image-processing library. One day every Payload route on the live site started returning errors: the admin panel, the API and the images. The homepage looked fine only because it was serving a saved copy it could no longer refresh. The cause was a mismatch between the library version our project needed and the copy of the supporting files that the build shipped to the host. It had been waiting since a security upgrade a month earlier, and it only appeared on the next rebuild. It did not reproduce on a local machine, because locally the right files were present.

The lesson is general: a green local build does not prove the deployed package is complete. After any dependency change that touches native code, check the live site, not just your laptop. Budget for this kind of maintenance; a CMS is software that needs looking after.

The public pages are cached for a few minutes. So a volunteer could save a change, refresh, and still see the old content for a few minutes, which looks exactly like a failed save. We added a small hook that runs after each save and tells Next.js to refresh the affected page. Payload documents that its afterChange hook runs after a document is created or updated; using it to refresh the page cache is our own pattern, and edits now show as soon as they are saved.

At first, some wording on the site was fixed in code, so every change needed a developer. We moved those sections into editable single-record entries, such as About and Services, so volunteers change the text themselves. The icons stay in code: an editor picks a name from a dropdown and the design system draws the icon. Payload's docs describe Globals as the primary way to structure singletons; on this site we used single-document collections with guards that stop a second copy being created or the last one being deleted. Either approach gives you the same outcome: editors change words, not layout.

Payload needs a developer to set up and to look after. There is no theme store to install a finished site from. If nobody on your side will touch code, and you do not have a developer on retainer, WordPress may be the more realistic choice. If a developer is involved either way, the extra control is often worth it.

If you are weighing the two, our headless CMS and Payload CMS service covers content modelling, user roles and moving an existing site across from WordPress. We will tell you if staying put is the better answer.