There is no such thing as the best “content management system” (CMS), the “engine” that drives a website. There is only the right one for a given project, team, and editorial reality. Which system you reach for ultimately depends on the project in question.
To be clear, this is not a comparison article. We’re not here to tell you that X is better than Y. Instead, this article offers an account of how we actually work, and why we have deliberately built fluency across several stacks rather than standardising on one.
The WordPress default, and its limits
Many agencies focus on WordPress for good reasons: it has an enormous ecosystem, near-universal name recognition among clients, and a low barrier to entry for non-technical editors. We have built, and will continue to build, websites in WordPress.
But WordPress has a gravitational pull that can distort a project. When every problem looks like it needs a plugin, you end up with plugin-dependent architectures that are difficult to maintain, slow by default, and structurally limited by what the ecosystem happens to offer. The CMS starts shaping the product rather than serving it. Features get scoped around what is available rather than what is appropriate; WordPress is bent and warped to fit the often changing needs of the client. Technical debt accumulates quietly behind a familiar interface.
There is also the question of longevity. WordPress sites built on a stack of third-party plugins are only as reliable as the slowest maintainer in the chain. A plugin abandoned by its author, a theme framework that stops receiving security updates, a page builder that rewrites its data model in a major version: these are not hypothetical risks. They are the normal lifecycle of a WordPress project that was not designed with long-term ownership in mind.
The question we ask before starting any project is: does it fit WordPress, or are we forcing WordPress to fit this project? If we’re clearly doing the latter, it’s time to consider something else. We’ve been there before!
Four tools, four kinds of work
In recent years, four platforms have earned a permanent place in how we build websites. These are WordPress, Laravel, Statamic, and, last but certainly not least, Processwire.
WordPress: for content-driven sites with non-technical editors
When a site is primarily editorial, when the client team will be publishing autonomously, and when the content model maps reasonably well to pages, posts, and custom fields, WordPress is still the most pragmatic choice. The editing experience is familiar, the plugin ecosystem covers most requirements without custom development, and clients can be genuinely self-sufficient after handover.
We use it for public-facing institutional and organisational websites where content volume is high and the editorial team does not have a developer nearby. The setup time is low, the hosting market is competitive, and the knowledge required to manage the site day-to-day is widely distributed.
But there are definitely tradeoffs. WordPress carries legacy architectural decisions that make performance and security meaningful ongoing concerns. Anything that departs significantly from the standard content model requires either a plugin compromise or substantial custom work, which increases the cost of the project. And the editing experience, while familiar, is not especially refined. For the right project it is still the most efficient path from brief to live site. For the wrong one, it introduces friction that compounds over time.
Furthermore, there is one reason to choose WordPress that sits in a category of its own: WooCommerce. For clients who need an online shop with real complexity, such as custom product types, conditional pricing, subscription logic, trade account tiers, or deep integration with an existing editorial site, WooCommerce occupies a useful middle ground. Shopify is faster to launch but walls you in quickly once your requirements diverge from the standard catalogue-and-checkout model. Full e-commerce frameworks, like Magento, or a Laravel-based system like Bagisto or Lunar, are built for genuine scale and bring corresponding complexity in setup, maintenance, and hosting.
WooCommerce sits between those two extremes: a serious shop on a platform most clients already understand, with a plugin ecosystem that covers a wide range of commercial requirements without necessarily commissioning a bespoke solution. It is not the right answer for every shop, but it could be just what you are looking for if you come at it with the right expectations.
Laravel: for complex systems and web applications
Some of what we build is not really a website at all. It is a data-driven application with a public face: a member portal, an industry registry, a workflow system with role-based access, complex relationships between entities, and business logic that no CMS was designed to express.
For these projects, we build using the PHP framework Laravel, used widely to create web applications. It follows the MVC pattern (model, viewer, controller), has an expressive ORM (Eloquent), a clean routing and middleware system, and a large ecosystem of first-party packages. It sits in the space between writing your own complete CMS – an exercise best left to those with too much time on their hands, believe us! – and a CMS in which the structure of your data is decided for you. With Laravel, you get strong conventions and excellent tooling without being constrained to a content model someone else designed, as is the case with WordPress.
With Laravel, the data model is whatever it needs to be. The business logic lives in the application layer, not in field-configuration workarounds. Relationships between entities are expressed as they actually exist, not approximated through taxonomies or custom post types. For a polished, flexible admin interface we rely on Nova, which ensures that we do not need to build an entire backend from scratch. For both developers and end users, Laravel + Nova is great to work with.
This is the most powerful option to build a large, modern website, but also the most expensive one. It requires proper development engagement, produces something that is not off-the-shelf in any sense, and puts the long-term ownership clearly on the agency unless the client has meaningful in-house development capacity. It is the right choice when the project really needs it.
One example is a white-label energy tariff platform we built for a client in the utilities sector. The system allows partners to embed customisable tariff comparison widgets into their own websites using a script tag and an API key. Each partner has its own project configuration in the Nova admin panel: branding, checkout URLs, tariff overrides, custom field values, and widget behaviour.
The backend for this project handles versioned REST endpoints, ZIP-code-based tariff lookups, and a flexible override system that lets non-technical administrators adjust pricing display and button behaviour without touching code. None of that has a sensible expression in any off-the-shelf CMS. The data model, the multi-tenant logic, the API layer, and the admin interface all needed to be designed around the actual requirements, not adapted from something built for publishing articles.
Statamic: for editorial sites that deserve a proper foundation
Statamic occupies a specific and genuinely valuable middle ground between a completely custom solution and a more standard CMS. It is built on top of Laravel, but stores content as flat files by default with database support available, and ships with a well-designed control panel that editors actually enjoy using. For projects where the editorial experience matters and the content model is meaningful but not wildly complex, it is often the best answer.
Where it earns its place is in projects where the client team has enough technical literacy to appreciate a thoughtful interface, and the development team benefits from working within a proper MVC framework rather than WordPress’s procedural heritage. Content lives in version-controllable files. Deployments are cleaner. The codebase is testable in ways that WordPress projects rarely are. Building custom fieldtypes, control panel views, or content workflows feels like writing Laravel code because it is.
We have used Statamic for editorial-heavy sites where content is structured, the client has some technical sophistication, and the long-term maintenance story matters. One thing worth being clear about: Statamic Pro requires a licence, which is a real line in the budget conversation. It is a reasonable trade for what you get, but it belongs in the estimate from the beginning.
For a certain class of project, the one that has outgrown WordPress, but does not need a fully bespoke application, Statamic is the most complete answer we have found. And the great advantage is that a project like this can be easily scaled up if necessary to make full use of what Laravel has to offer. For some projects, for example, we mix Statamic with a Nova backend, keeping editorial matters in Statamic’s control panel while handling more complex data, that does not need to be modified by regular content editors, via Nova.
ProcessWire: for developer-built multilingual sites
ProcessWire is what happens when a CMS is designed by someone who wanted maximum flexibility and had no interest in making it easy for non-developers. That is a feature, not a criticism. It is completely agnostic with regards to data, but does require all information to be organized in pages: its web structure is also its data structure.
However, the data model is genuinely granular. Fields, templates, and page trees can be composed into almost any structure without fighting the framework. Multilingual support is first-class and built in rather than bolted on as an afterthought. The API is clean and consistent. And the codebase stays lean: there is no extensive plugin ecosystem to depend on, which means there is also nothing to become a liability.
We reach for ProcessWire on sites that require bespoke features and data structures, but where using WordPress would make little sense but for which Laravel is clearly overkill. It rewards precise thinking about content structure and has no strong opinion about what a page should look like or contain. The absence of off-the-shelf templates is the point: you build exactly what the project requires, and nothing it does not.
The downside is exactly what makes it a strong choice. There is no large community of ready-made plugins to draw from, and no marketplace of themes to accelerate early decisions. However, it does offer a convenient backend interface that a content editor will immediately feel at home in. It is the perfect system to build something bespoke without going all-in on a large and complex application like Laravel.
How we actually decide
The decision framework is less glamorous than it sounds. Most of it comes down to a handful of questions asked early, ideally before anyone has an opinion to defend.
Who edits this content, and how often? Non-technical editors who need to be independent point toward WordPress or Statamic. Those who are not afraid to get over a small learning curve can also handle Processwire, especially when multilingual options need to be front and centre.
How complex is the underlying data model? Standard posts and pages point toward WordPress. Structured but non-relational content points toward Statamic or ProcessWire, whereas relational data with meaningful business logic points toward Laravel.
Is multilingual support a requirement from day one? ProcessWire and Statamic handle this more naturally than WordPress, where multilingual support has historically been a plugin concern and the results vary widely.
What does long-term ownership look like? A client with no in-house technical resource needs a system that ages gracefully without constant intervention. That changes the calculus significantly.
What is the actual budget across development, licensing, and maintenance? These numbers interact in ways that are not always obvious at the start. A lower-cost CMS that requires more bespoke development can end up more expensive than a licensed platform with better built-in tooling.
No single platform wins every one of these questions. The point is to ask all of them before committing to an answer.
Nimbleness as a service
There’s a straightforward version of this where you pick one platform, get very good at it, and that’s your offer. Plenty of agencies do exactly that, and it works. The tradeoff is that every project gets the same answer before the questions have been asked. The recommendation precedes the diagnosis.
We’ve gone a different way, and honestly it’s harder. Maintaining real fluency across several systems requires not just familiarity, but the kind of knowledge that lets you say “this will cause you problems in two years”. It takes time to build and requires turning down work that doesn’t fit rather than stretching a platform to cover it.
Whether that’s a better bet is something we’re still finding out. What we can say is that when we recommend a system, it’s because we’ve built real things with it, hit its limits, and decided it was still the right tool for a certain kind of job. Not because it was what we used last time, or because it’s what the client already knows the name of.
That’s what we’re trying to offer. Whether it’s what you need is a different question, and worth asking before we get started.
