Here’s a pattern we see constantly: a client comes to us already sure they want WordPress, or already sure they want something “more modern” than WordPress, before we’ve talked about a single requirement. Most CMS decisions get made this way, backwards. The platform gets picked first, and the requirements get bent to fit it afterwards.
We’ve spent years doing the opposite. We build across WordPress, Payload CMS, Statamic and Craft, and which one a project actually lands on depends entirely on what that project needs to do.
This isn’t a shoot-out, and we’re not going to pretend one platform quietly wins by the end. Each one is the right answer to a particular set of requirements. The skill isn’t in loving one of them, it’s in reading the requirements clearly enough to know which one you’re looking at.
The decision comes before the platform
Before a single line of code gets written, a handful of questions decide almost everything:
- Who edits the content, and how often?
- How many languages, and are they translations or genuinely different markets?
- Does the system need to talk to an ERP, a CRM, an internal tool?
- Will the design outlive the content, or the other way round?
- Is this a website, or a website and an application behind one login?
- How AI-addressable does this need to be a year from now?
Answer those honestly and the platform mostly picks itself. Skip them, and no platform will save you.
The most expensive CMS decision isn't picking the wrong platform. It's picking one before you know the requirements.
WordPress – when editorial comes first
WordPress still earns its place when the editorial experience is the whole point – a content team publishing daily, and non-technical editors who need to work confidently without breaking things.
The Gutenberg editor strikes a decent balance between flexibility and usability, and reusable blocks and patterns give editors structure without taking away their control. Recent versions have also added machine-readable APIs that let AI agents interact with a site directly, which we dug into in WordPress 7.0 Just Became an AI Platform.
It’s also, in practice, the platform behind most of our client work. Editorial teams publishing regularly are simply the most common shape of project we see.
Payload CMS – when the structure is the product
For custom or complex builds – intricate data models, multi-step workflows, a frontend that needs to be genuinely fast – we reach for Payload instead. It’s code-first, with typed content models, auto-generated REST and GraphQL APIs, and an admin panel editors pick up without much training. Because it’s headless, content and frontend stay decoupled – so a redesign two years from now only touches the frontend, not the CMS underneath it.
That was the shape of a recent project for a motorcycle retailer we worked with. There was enough structural complexity that a code-first, typed system saved real time over trying to force it into a template-driven platform.
Most CMS headaches come from plugins nobody controls. Payload has none of that – it's our code, typed, top to bottom, so there's far less to go wrong two years in.
More on why Payload became our default for new projects and why its structured content is already AI-ready.
Statamic – one login for the website and the tool behind it
Some projects aren’t just a website. They’re a website and an internal tool – a portal, a booking system, a dashboard – and the client experiences them as one thing. With Statamic, the public site and the admin application live in one codebase, behind one login, with one permission model.
We ran into this exact problem with a Swiss print and merchandise company and, separately, a podcast production studio. Both were already running on a Laravel-based platform we’d built and maintained for them, their actual business tool, not just a website. When they came to us needing a blog and general content capability added on top, the obvious-but-wrong move would have been bolting on a separate CMS: a second login, a second permission model, two systems slowly drifting out of sync. Statamic let us add the content layer inside the existing Laravel application instead, behind the login the client was already using every day.
Craft CMS – structured content and worth watching in 2026
When editors need serious control over structured, relational content – a large catalogue, a complex publication, per-field control over how each market differs – Craft is built for exactly that. It uses flexible, mix-and-match content fields editors can rearrange per page (Craft calls these “Matrix fields”), plus genuine per-field localisation. Through 2026 it’s also modernising its foundations, which is why it’s one we’re actively positioning for content-heavy projects needing both editorial depth and multi-site support.
Comparing the four systems – without picking a favourite
| WordPress | Payload | Statamic | Craft | |
|---|---|---|---|---|
| Built for | Editorial sites, big ecosystem | Custom / headless apps | Site + app as one product | Structured, relational content |
| Editor experience | Gutenberg, familiar | Clean, trainable admin | Minimal, only needed fields | Deep, field-level control |
| Multi-language | Strong (plugins) | Built-in, structured | Built-in | Per-field localisation |
| App + CMS in one | Add-on | Possible | Native, one login | Possible |
| AI today | 6.9 / 7.0 AI APIs | Structured = AI-ready | API-addressable | Structured content |
| We pick it when | Editors + ecosystem lead | Structure is the product | Site and app are one | Content depth leads |
If you could sum a column and crown a champion, this table would be doing its job badly. WordPress on a headless app build, Payload on a five-page brochure, Craft on a two-page microsite, each would be a mismatch, and none of it is the platform’s fault. It isn’t about replacement, it’s about differentiation: the right tool for the right project.
How we actually choose
We start with your requirements, not our preferences. We map out who edits, how many markets are involved, what it needs to integrate with, how the design and content will age, and how AI-addressable it needs to be a year or two out. Then we match that to WordPress, Payload, Statamic or Craft.
Sometimes the answer is the platform you’d expect. Often it isn’t. The print and podcast clients above are a good example: nobody would have guessed Statamic from the outside, but it was the only platform that let us add content capability without handing the client a second login to manage. Either way, the reasoning is something you can see and question.
Already on something else entirely? We maintain and migrate legacy systems too, including Django CMS. That’s a separate decision from which of the four platforms above fits a new build, and one we cover in our guide to CMS migration.
Work with a team that picks the platform to fit the project
If you’re weighing a new build or a replatform and you’d rather start from requirements than a logo, we’d love to talk. At what., we build across WordPress and Payload, and Statamic and Craft where they fit, backed by 10+ years and 2,000+ delivered projects.
Also relevant: if your project needs to work across German, French, Italian and English, the platform is only half the decision. See our companion piece, Most Swiss Websites Aren’t as Multilingual as They Think.
What our clients ask us
FAQs
Which CMS is the best?
None of them, honestly, and any of them, for the right project. “Best” only starts to mean something once you’ve defined who edits, how many languages you need, what it has to integrate with, and how it needs to scale.
