WordPress vs Custom-Coded: Which Should Your Business Actually Use?

As of 5 August 2026, W3Techs measures WordPress at 41.2% of all websites and 59.1% of sites whose CMS is known. Whatever else is true, that is the default of the web, and the practical consequences are real: an enormous plugin and theme ecosystem, a deep pool of people who can work on it, and a hiring market where replacing your developer is straightforward.

You will see wildly different figures quoted — anywhere from the low thirties to the low forties — and the discrepancy is methodological rather than anyone lying. W3Techs counts subdomains of one site as a single entry; other trackers count them separately, and different samples of "the web" produce different denominators. When someone quotes a WordPress share, the useful question is which tracker and which date.

The trap is treating that share as a recommendation. "41% of websites use it" tells you that most websites are content-shaped, which has always been true. It tells you nothing about whether your customer portal, booking engine, or data-heavy dashboard belongs on it. Popularity is a fact about the web, not advice about your project.

This is where the conversation usually collapses into slogans, so let's use the numbers. Patchstack's State of WordPress Security in 2026 report found 11,334 new vulnerabilities across the WordPress ecosystem in 2025 — a 42% increase on 2024. That sounds like a damning verdict on WordPress. Read the breakdown and it says something much more precise.

Of those vulnerabilities, 91% were in plugins and 9% in themes. WordPress core accounted for six. Six, out of more than eleven thousand. So "WordPress is insecure" is simply not what the data shows — WordPress core is, by this measure, remarkably well maintained. What is insecure is the third-party plugin ecosystem that the average site bolts onto it, and which most site owners install without any review of who maintains it or whether they still do.

Two further findings make the practical risk concrete. Patchstack puts the weighted median time from public disclosure to first exploitation attempt at five hours for heavily exploited vulnerabilities, with roughly half of high-impact issues exploited within a day. And 46% of vulnerabilities had no patch available from the developer at the moment they were disclosed. Together those mean a plugin-heavy site is in a race it cannot always win by patching promptly — sometimes there is nothing to patch yet.

The correct conclusion is not "avoid WordPress." It is that on WordPress, **your plugin list is your attack surface**, and it deserves the same scrutiny as any other dependency you take on: how many do you really need, who maintains each one, are they still actively updated, and who is responsible for applying patches within hours rather than months. A custom-coded site is not automatically safer — it has its own dependencies — but it typically has far fewer of them, and they are chosen deliberately rather than accumulated.

Set aside ideology and compare the dimensions that show up in daily use. Neither column is a winner — each is a different set of trade-offs, and which set suits you is the whole decision.

We build custom software for a living and we still tell clients to use WordPress when it fits. Recommending against your own margin is the only way advice like this is worth anything, so here is the honest list.

Choose WordPress when the site is content-led and the budget is modest: a marketing site, a blog, a news or magazine format, a portfolio, a small brochure site with a few pages you want to edit yourself. Choose it when publishing frequently matters more than doing anything unusual, when a non-technical team must own day-to-day updates, or when you need something respectable live in days rather than weeks. Choose it when your requirements are genuinely standard — because in that case, a mature plugin has already solved your problem better than a rushed custom implementation would.

One condition though, if you go this route: be disciplined about plugins. Every one you add is a dependency you are responsible for patching, and the data above explains why that responsibility is not theoretical. A lean WordPress site with a handful of well-maintained plugins and prompt updates is a perfectly sound, defensible choice. A site with forty plugins, six of them abandoned, is a breach waiting for a schedule.

Custom wins when the site is a piece of your business rather than a description of it. The clearest signal is when you find yourself asking whether a plugin exists to do something quite specific to how you operate — that question means you are trying to bend a content tool into an application, which is the point where plugin-stacking starts costing more than building would have.

It also wins on performance when performance is competitive rather than cosmetic. A custom build runs exactly the code you put in it: no theme framework, no plugin loading assets on every page, no query overhead from features you never use. That control is what makes it possible to be genuinely fast on a mid-range phone on 4G, which — as we covered in why your website feels slow on mobile — is where visitors actually are, and where slowness quietly costs you conversions.

And it wins whenever the site must be truly yours: unusual integrations with systems that have no plugin, workflows that are your competitive advantage, a design that has to look like nobody else's, or a compliance posture where "a third-party plugin has access to customer data" is not an acceptable sentence. If any of those describe you, the custom build is not the expensive option — it is the one that does not have to be replaced in two years.

Page builders deserve their own answer, because they are how most WordPress sites are actually built today and they change the trade-offs meaningfully. They are genuinely empowering: a non-technical owner can restructure a page visually without touching code, which is a real capability and the reason they are so widely adopted.

The cost is weight and lock-in. Builders ship their own rendering layers, stylesheets, and scripts on every page — often loading assets for features a given page never uses — which is why builder-heavy sites so often fail mobile performance targets despite looking fine on a desktop demo. They also mark up your content in their own structures, so leaving the builder later usually means rebuilding the pages rather than exporting them. That is a plugin you cannot easily remove, on top of the plugin-surface question above.

The pragmatic position: if you are on WordPress and a builder is what makes you self-sufficient, use one — that autonomy has real value, and one well-chosen builder is a far smaller risk than twenty miscellaneous plugins. Just budget for the performance work, keep the page count of builder-heavy templates modest, and go in knowing the exit cost. If instead you are optimising for speed and clean ownership from the start, that is precisely the case where a custom build with a headless CMS gives you the visual editing without the runtime tax.

Almost every comparison of these two options stops at the build price, which is exactly the wrong place to stop. WordPress usually wins launch day. The interesting comparison is what each has cost you thirty-six months later, and that depends far more on your trajectory than on the platform.

If the site stays what it is — content, updated regularly, no new mechanics — WordPress very likely stays cheaper the whole way, and choosing it was correct. The costs that accumulate are premium plugin licences, hosting suited to a database-backed CMS, and maintenance attention that is genuinely ongoing rather than annual.

The picture inverts if you keep asking the site to do more. Each new requirement becomes another plugin, each plugin adds weight and attack surface, and eventually something has to be forced to work in a way it was not designed for. That is the point where teams commission the rebuild they were trying to avoid — and pay for the site twice. The honest test is not "which is cheaper?" but "which am I likely to be?" A business whose site is a brochure in three years should buy the brochure. A business whose site is becoming a product should build it like one.

This is the same trade-off, in a different costume, as the one between no-code tools and custom development for product builds — the reasoning transfers cleanly, and we laid it out in custom development vs no-code.

Ask yourself one question and the answer usually falls out: **in three years, is this site describing my business or running part of it?** Describing means content — WordPress, kept lean, is a sound choice and you should not pay more for the privilege of a custom build. Running means behaviour — custom, and the sooner you accept that the less you pay in total.

If you genuinely cannot tell yet, there is a cheaper move than guessing: start with the content site, keep the design and copy assets you paid for, and build the application layer when the need is real rather than hypothetical. Nothing is wasted, and you avoid buying a platform for requirements that never materialise.

What we do, when clients ask us this, is answer it on their facts rather than ours. We build custom web applications — that is our business — and we still recommend WordPress when the site is content-led and the budget is better spent elsewhere. If you want that call made honestly, the scoping conversation is free, and you will get a fixed written quote for whichever direction is genuinely right. Costs for both paths are laid out in how much a website costs in 2026.