WordPress vs. Custom-Built: The Question We Get Wrong Most Often

Every few weeks, someone asks us to weigh in on WordPress versus a custom build, and they're expecting a technology answer: page speed, security patching, plugin bloat, developer availability. Those factors matter, but they're not why most of our recommendations go one way or the other. The real question is almost never asked out loud: how much is this business going to change in the next two years, and in what direction?

WordPress is genuinely good at the thing it's good at

A marketing site, a blog, a brochure site for a professional services firm, a restaurant's menu-and-hours page: WordPress (or any mature CMS) handles this well. Content editors who aren't developers can update copy without filing a ticket. The plugin ecosystem covers 90% of common needs. Hosting is cheap and widely available. If your site's core job is "present information and get updated by a marketing person," a CMS is the right call almost every time, and we say so even when a custom build would earn us more.

Where it stops being the right call

The trouble starts when a site's requirements grow sideways instead of just getting more content. A booking flow with real-time availability. A customer portal with logins and role-based views. Integration with an inventory system that has to stay in sync in near real time. A checkout flow with business rules that don't map onto a standard plugin's assumptions.

At that point, every plugin you add to bridge the gap is a future maintenance liability: a security surface you didn't build and don't fully understand, a compatibility risk every time WordPress core updates, and a performance cost that compounds as you stack more of them. We've inherited sites running eleven plugins to do the work three well-written custom modules would have handled, and every update cycle was a small gamble on whether something would break.

The question that actually predicts the right answer

Instead of "how complex is this today," ask "what does this need to do in eighteen months if the business succeeds." A five-page company site that might grow a careers section and a blog stays a CMS forever, comfortably. A site that's currently "just a catalog" but where the founder mentions, almost in passing, that they want online ordering next year and a loyalty program the year after: that's a custom build wearing a simple-site disguise, and building it on WordPress now means a full re-platform later, at a worse time, under more pressure.

We ask this question explicitly in discovery, and we've talked clients out of both directions: away from an unnecessary custom build for a site that will stay simple, and away from a CMS-plus-fourteen-plugins setup for a site that's clearly headed toward operational complexity a CMS was never designed to carry gracefully.

The middle path people forget exists

It's also not always binary. A common, underused pattern: a CMS for the marketing site and content, with a custom-built application handling the operational core (bookings, accounts, inventory), connected through an API. Marketing keeps editing content without a developer. The parts that actually need engineering discipline get it. Neither system is stretched to do a job it wasn't built for.

If you're mid-debate on this for your own project, the honest first move isn't picking a technology. It's writing down what the business is actually going to need to do in two years, not what the site needs to display today. The technology choice mostly falls out of that answer on its own.