WordPress as a serious platform: when complex builds make sense, and when they don’t

WordPress has a credibility problem in technical circles that the numbers don’t really justify. It runs roughly forty percent of the public web. It powers government estates, national newsrooms, FTSE-100 marketing sites, and — relevant to us — an AI marketing automation plugin we’ve built and shipped to three named external customers.

The technical critique of WordPress is usually pitched against a particular kind of bad WordPress build: the cheap brochure site with thirty unmaintained plugins, a free theme that’s been modified beyond recognition, and a hosting plan with no observability. That’s a real category of WordPress site. It’s also not what serious WordPress engineering looks like.

This piece is about where the serious end actually sits — when WordPress is the right tool for a complex build, when it isn’t, and how to tell the difference before you commit.

Where WordPress earns its place

Three patterns where WordPress is genuinely the strongest option, not a compromise.

1. Content-heavy products with non-technical editors. If your operating reality involves marketing teams, communications staff, or domain experts publishing structured content on a regular cadence, WordPress’s editor experience is unmatched by anything else in its weight class. Headless CMS alternatives (Contentful, Sanity, Strapi) win on developer ergonomics but lose on author experience, training cost, and recovery time when a senior comms person leaves and a new one has to ramp up in a week.

2. Sites that need editorial workflows on top of a custom front-end. WordPress runs perfectly well as a headless CMS feeding a Next.js or Nuxt front-end via the REST API or GraphQL. You get a serious React/Vue front-end with bespoke logic, and the editor workflows that come for free with WP. We’ve shipped this pattern for customers in legal and media — Clarke Willmott and Burlington Media among them.

3. Bespoke product features delivered as WordPress plugins. This is where BisonPress lives. BisonPress is an AI marketing automation WordPress plugin — a custom plugin, written by us, that ships AI-driven workflows into the editor experience. Three external customers run it in production: Herd Group, New Team Services, and Siem Car Carriers. The plugin architecture gave us SSO, role management, content modelling, REST endpoints, and a CMS surface area for free. We wrote the AI integration and the workflow logic. We did not write user authentication.

Where WordPress is the wrong tool

Equally important. Three patterns where reaching for WordPress is the source of the problem, not the solution.

1. Highly transactional systems. If the core thing your product does is handle thousands of writes per minute against a relational database — ePOD scans, real-time vehicle tracking, financial transactions, ticket processing — WordPress’s data model and request lifecycle fight you. The right tool is a bespoke application with a real ORM, properly designed schema, and a runtime tuned for write-heavy workloads. We build those for our shipping and logistics customers; we don’t try to do them inside WordPress.

2. Real-time or near-real-time operational data. WordPress is request-response. Long-lived connections, WebSockets, server-sent events for live operational dashboards — possible to bolt on, but you’re working against the platform. For Bison Insights and Bison Track, we use a different stack entirely.

3. Multi-tenant SaaS with complex per-tenant data isolation. WordPress Multisite is excellent for editorial multi-tenancy (a publisher with twenty regional sites). It’s wrong for SaaS multi-tenancy where each tenant has materially different data models, integrations, and security boundaries. Build the SaaS bespoke.

What a “complex” WordPress build actually involves

The price band for a complex WordPress build at our end of the market starts around the £25–80k Mid-market range and can run into the £80–150k Complex Build range when the brief involves regulated-sector compliance, deep integrations, or substantial custom plugin work. What does the money go on?

• Custom post types and a properly designed content model. Not Advanced Custom Fields bolted onto pages and posts as an afterthought. A real content model that survives editorial reality.
• Performance engineering. Object caching, page caching strategy, query optimisation, asset pipeline. The difference between a fast and a slow WordPress site is mostly engineering, not hosting tier.
• Hardening. Disabling unused REST endpoints, two-factor on every privileged account, properly scoped database users, application-level rate limiting, a sensible WAF, log shipping to somewhere you can actually grep.
• Deployment pipeline. Versioned, environment-separated, reproducible. WordPress is famously easy to develop on — and famously hard to deploy responsibly. The fix is the same as for any other system: proper CI/CD, environment parity, database migration discipline.
• Custom plugins. Sometimes one or two — to handle the integration your business actually depends on. Treat them as application code, with tests, with a release process, with code review.

If a “complex WordPress build” doesn’t include those things, it’s a brochure site dressed in complex-build clothes. That’s the failure mode we see most often.

How to tell which side of the line you’re on

Five questions, honestly answered:

1. Is the primary user a content editor, or an operational user transacting against business data?
2. Is the request-response model a comfortable fit for what you’re trying to do, or are you fighting it?
3. Does the value of your platform live in the content and the editorial workflow, or in custom business logic and data?
4. Are you optimising for editor experience and ramp-up time, or for engineering velocity on application features?
5. Are you a single-tenant product (or a small handful of editorial sites), or a true multi-tenant SaaS?

Answer the left side of those questions, and WordPress is probably the right call — at the complex-build level, with proper engineering discipline. Answer the right side, and you want a bespoke application.

Our honest take

We do both. Complex WordPress builds are a real service line for us, and BisonPress is itself a complex WordPress engineering project shipped as a product. We’ve also shipped bespoke applications — BisonGrid, Bison Exchange, Bison Insights — where WordPress was the wrong tool and we chose accordingly.

The trap is treating “WordPress” as one thing. A £4,000 brochure site and a £120,000 complex WordPress build share a name and almost nothing else. If you’ve been told WordPress can’t be serious software, you’ve been told something that isn’t true. If you’ve been told WordPress is the right tool for every job, that isn’t true either.

The serious question is what you’re trying to do. The boring answer is usually the right one.

---

Team Bison is the software, AI and operations consultancy within the Bison Grid Ltd group. We’ve been building production software — including complex WordPress builds and bespoke applications — for shipping, vehicle logistics, NHS, legal and medical customers since 2003.