"Just use WordPress." It comes up in almost every scoping conversation. Half the time, it is the right call. WordPress powers a quarter of the web for good reason. But the other half of the time, it is the start of a costly architectural mistake that takes years to unwind.
What You Need to Know
- WordPress is excellent for content-driven sites and marketing pages
- It becomes a liability when organisations try to build complex workflows, portals, or internal tools on top of it
- The real cost isn't the initial build, it's the years of workarounds, plugins, and maintenance that follow
- Knowing where the line is saves enterprises hundreds of thousands of dollars
The Numbers
25%
of all websites globally run on WordPress
Source: W3Techs, January 2016
That's a staggering number. And it makes sense. For blogs, marketing sites, content hubs, and basic e-commerce, WordPress is fast to set up, easy to manage, and has a plugin for almost anything you can think of. Our team has built dozens of WordPress sites. We're not against it.
But market share and suitability aren't the same thing. Plenty of organisations choose WordPress because it's familiar, not because it fits.
Where WordPress Works
Content sites. Brochure sites. News and media. Event promotion. Basic e-commerce with WooCommerce. Campaign microsites.
These are problems WordPress was designed to solve. The CMS is intuitive. The theme ecosystem is mature. You can get a site live in weeks, and a non-engineering editor can manage content without calling a developer. That's genuinely powerful.
If your project is primarily about publishing and presenting content, WordPress is probably the right choice. We'll tell you that in the scoping meeting.
Where It Falls Apart
The trouble starts when the brief goes beyond content.
Custom workflows. "We need staff to submit applications, have managers review them, route them to the right team, and track status through to resolution." You can build this on WordPress with a stack of plugins. We've seen it done. It works on day one. By month six, the plugin conflicts start. By year two, you're maintaining a Frankenstein system that nobody wants to touch.
User roles and permissions. WordPress has roles. It doesn't have the fine-grained, context-aware permissions that enterprise applications need. "This user can see their own submissions, their manager can see the team's submissions, and the admin can see everything" sounds simple. In WordPress, it's a custom plugin or a hack on top of a hack.
Data relationships. WordPress stores content. It isn't a relational database with proper data modelling. When your application needs to track entities with complex relationships (clients linked to cases linked to assessments linked to outcomes), you're fighting the data model rather than using it.
Integration. Modern enterprise systems need to talk to other systems. APIs, data feeds, authentication against corporate directories. WordPress can do some of this. But every integration is a custom plugin or a bolt-on, and the maintenance cost compounds.
The most expensive WordPress projects we have seen were not expensive to build. Three years in, the organisation is spending more on keeping the plugins working together than it would have cost to build the right system from scratch.
John Li
Chief Technology Officer
The Plugin Problem
A 2015 analysis by WP WhiteSecurity found that over 50% of WordPress vulnerabilities came from plugins. That's not a knock on plugin developers. It's a structural issue. When you're assembling an application from fifteen different plugins built by fifteen different teams, you're taking on fifteen different maintenance burdens, update cycles, and security surfaces.
For a marketing site with a handful of plugins, this is manageable. For an enterprise application running critical workflows on a dozen plugins, it's a risk that compounds over time.
52%
of WordPress vulnerabilities relate to plugins
Source: WP WhiteSecurity, 2015
The Real Decision
The question isn't "WordPress or custom?" It's "what are we actually building?"
If you're building a site that publishes content and needs to look good, WordPress is fast, proven, and cost-effective.
If you're building an application that manages data, enforces workflows, handles complex permissions, and integrates with other systems, you need an application framework. Node, Laravel, .NET, Rails. Something designed for the problem you're solving.
The worst outcome is starting on WordPress because it's cheap and familiar, then spending the next three years patching it into something it was never meant to be. We've inherited those projects. The rewrite always costs more than building it right would have.
How We Handle It at IDESIGN
When a client says "just use WordPress," we don't argue. We ask questions.
What does the system need to do in two years? Who uses it and how? What other systems does it need to talk to? How many users? What are the security requirements?
If the answers point to WordPress, great. Faster to build, cheaper to maintain, and the client gets a system they can manage themselves.
If the answers point to something more complex, we explain the trade-offs honestly. Not to upsell. Because building the wrong thing on the wrong platform is something we've seen go badly too many times, and nobody wins when it does.