Enterprise WordPress development

“Enterprise” is used loosely enough in WordPress to have stopped meaning anything. It is worth replacing the adjective with the conditions it is standing in for, because those conditions are what change how a project has to be built. It is entirely possible to have a large budget and none of them, or a modest budget and all six.

Complex platforms fail in the plan, not in the syntax. The decisions that are expensive to reverse (how content is modelled, where each piece of data is authoritative, how the site is split into sites, how editors will actually work) all get made in the first weeks, and most of them are made implicitly if nobody makes them deliberately.

We start with a written architecture: the content model and the relationships in it, the integration map with the direction and frequency of every data flow, the environment and release plan, the editorial roles, and the parts of the system that are deliberately out of scope. It is short, it is reviewable by people who are not developers, and it is the thing a second developer reads in two years to understand why the platform is shaped the way it is.

This is also what makes a fixed-scope tender response possible. A phased estimate is only meaningful if the phases correspond to decisions someone has already made.

Most enterprise WordPress problems present as editorial complaints: the site is slow to update, nobody can find anything, two teams have published contradictory versions of the same thing. Almost all of them are content model problems underneath.

In the platforms we build, WordPress is usually the presentation and editorial layer over data that belongs somewhere else. That is a design position, not a limitation: the integration is what keeps the website accurate without asking anyone to maintain the same record twice.

In delivered work this has meant broker, office and franchise data from a client’s own CRM, calendar and scheduling services, mapping and location services, payment processing, weather and external data feeds, consent management, and analytics and tag management, all built against documented APIs with caching, logging and defined behaviour when the upstream system is unavailable.

The last part matters more than the integration itself. An integration that works is ordinary; an integration that degrades predictably when the other system is down, rate-limited or returning something unexpected is the difference between a platform and a demo.

Enterprise delivery is mostly about making changes boring. The platforms we run are deployed from version control through a build pipeline into staged environments (local, staging, production) with the same build producing the same artefacts each time, and a documented path back if a release goes wrong.

We have delivered this on cloud infrastructure, including Azure virtual machines with CI/CD pipelines, and on conventional managed hosting. The infrastructure is chosen to fit the client’s IT constraints rather than our preferences. Where an organization needs standalone managed hosting rather than a development partner, we will say so and point them elsewhere rather than sell it.

At scale the ordinary WordPress advice stops being sufficient. Performance work becomes query and content-model work: an unindexed meta query over fifty thousand records will not be rescued by a caching plugin, and a page that assembles twelve external calls per request needs its data strategy fixed rather than its cache warmed. We work on Core Web Vitals from the template and query layer up, with caching as the last step rather than the first.

Security at this level is mostly governance. Who has an administrator account and why, how credentials are stored, which plugins are permitted and who approves a new one, how quickly a critical patch gets applied, and what the recovery procedure actually is. We document these as part of handover because they are the questions an IT reviewer asks in procurement, and because a platform with no named owner for them is one staff change away from being unmaintained.

Where an organization runs several related sites, whether divisions, brands, regions, campaigns, or an English and a French presence, a multisite network lets them share a codebase, a design system and a release process while keeping content and permissions separate. It is the right answer often, but not always, and the decision belongs in the architecture phase rather than in the build.

An enterprise platform is not finished at launch; it enters its longest phase. We stay on as the development team, covering core and plugin updates, security patching, monitoring, integration changes when an upstream API version moves, performance work as content grows, and new development as requirements change. It is handled by the people who built the thing, working against the architecture they wrote down.

Where an organization would rather bring the work in-house or move it to another supplier, the handover is the documentation, the repository and the architecture record. A platform you cannot hand over is a platform you do not own.