But here's what that 43% figure doesn't tell you. It doesn't tell you how many of those sites are abandoned staging installs that never went live. It doesn't tell you how many are running outdated themes riddled with security holes. And it certainly doesn't tell you about the business owners who, three or four years in, find themselves stuck with a website they can't update without something breaking, loaded with code they don't need and dependencies they never asked for.
That's technical debt. And it's one of the main reasons we at Pedwar build websites from scratch rather than layering them on top of WordPress themes and plugins.
Technical debt is a term borrowed from software engineering. It describes the accumulated cost of shortcuts and compromises that were convenient at the time but create problems down the line. In practical terms, it's the digital equivalent of bodging a repair instead of doing the job properly. The short-term result looks the same, but you're storing up trouble.
For WordPress sites, technical debt accumulates in specific, predictable ways. Every theme you install brings with it thousands of lines of code you'll never use. Every plugin adds its own stylesheets, JavaScript files, and database queries. Each one is a small compromise. Individually, they seem harmless. Collectively, they can turn a website into a slow, fragile, hard-to-maintain mess.
The real sting is that this debt is invisible at launch. A brand-new WordPress site with a premium theme looks great and loads reasonably fast. It's only over months and years that the interest payments start to bite.
WordPress itself is a content management system. Out of the box, it handles posts, pages, and basic media. Everything else requires plugins: contact forms, SEO tools, security features, e-commerce, backup systems, image optimisation, caching. The WordPress plugin directory lists over 59,000 free plugins, and there are thousands more available as paid options.
This sounds like a strength, and in some ways it is. But it creates a fundamental architectural problem. Your website becomes a patchwork of code written by dozens of different developers, all with different coding standards, different update schedules, and different levels of commitment to long-term maintenance.
Each plugin you add can introduce its own scripts, stylesheets, and database tables. Page builder plugins alone can generate 10 to 15 additional HTTP requests per page load. Slider plugins add another five to eight. Social sharing widgets can pile on anywhere from two to twenty more. A WordPress site that started out lean can quickly end up making over 100 HTTP requests per page, each one adding latency and slowing down the experience for your visitors.
And here's what most people don't realise about deactivated plugins: turning a plugin off doesn't clean up after it. Database tables, settings, leftover files and orphaned entries all remain. The plugin is gone, but its footprint stays behind, cluttering your database and adding weight to every query your server runs.
Every plugin on your site is a dependency you don't control. The developer might lose interest, get a new job, or simply stop maintaining it. When that happens, you're left with code that will never receive another security patch or compatibility update.
An abandoned plugin needs a plan: check whether it has known vulnerabilities, whether someone can maintain it, and whether it should be replaced. Removal from a directory does not itself remove the installed copy from a website.
If an abandoned plugin handles an important booking journey, form or integration, review the consequences before changing it. Replacement may require data migration or redevelopment; the work depends on the component and how the site uses it.
According to Patchstack's 2026 State of WordPress Security report, 11,334 new vulnerabilities were identified across the WordPress ecosystem in 2025. This is a count of discovered vulnerabilities, not the number of successful breaches or the chance that any particular site will be compromised.
Of those vulnerabilities, 91% were found in plugins and 9% in themes. Only six were in WordPress core itself. The core software is actually quite well maintained. The problem is everything that gets bolted onto it.
What makes this particularly uncomfortable is the myth that using popular, well-known plugins guarantees safety. It doesn't. Patchstack found 1,018 vulnerabilities in 2024 in components with at least 100,000 active installations. Popularity doesn't equal security. If anything, a high install count makes a plugin a more attractive target.
A bespoke build can avoid a WordPress theme and plugin stack, but it is not immune to vulnerabilities. The application, third-party libraries, runtime and hosting environment remain part of the security picture. Dependencies need tracking, and updates, testing and monitoring still matter.
Speed matters. Google uses Core Web Vitals as a ranking factor, measuring loading speed, interactivity, and visual stability. Research consistently shows that over half of mobile visitors abandon a site that takes longer than three seconds to load, and that each additional second of delay costs you conversions.
WordPress themes, even the well-regarded ones, carry overhead. Multi-purpose themes are the worst offenders. They ship with built-in support for dozens of features, layouts, sliders, animations, and page builder integrations, whether your site uses them or not. All of that code gets loaded on every page visit. Fancy animations, complex header layouts, and client-side rendering frameworks that your particular site might not need at all are still there, consuming bandwidth and processing time.
The industry's answer to this has been to pile more solutions on top. Caching plugins. Image optimisation plugins. Code minification plugins. CDN integrations. Each one is another plugin, another set of dependencies, another potential point of failure. You end up in a situation where you need plugins to fix the performance problems caused by other plugins and the theme itself. There's a dark comedy in paying for a caching plugin to compensate for the bloat introduced by a page builder you're also paying for.
A bespoke build lets the developer focus on the features the site actually needs. That can help reduce unnecessary code, but performance is not automatic: images, scripts, caching, database queries and hosting still need attention.
Running a WordPress site means running a constant cycle of updates. WordPress core updates. Theme updates. Plugin updates. PHP version updates on the server. Each of these can introduce compatibility issues, and they update on independent schedules controlled by different developers.
This creates a web of interdependencies that's genuinely fragile. Your theme needs to be compatible with the current version of WordPress. Your plugins need to be compatible with both the theme and the WordPress version. Everything needs to work with the PHP version your server is running. Change any one piece and the others might break.
Ask anyone who manages WordPress sites professionally and they'll have stories about clicking the update button and watching a live site collapse. Themes that aren't prepared for a WordPress core update. Plugins that conflict with each other after one of them updates. Custom modifications made directly to theme files that get silently overwritten the next time the theme updates. E-commerce sites seem to get hit hardest because WooCommerce interacts with so many other components that any update can cascade through the entire system.
The recommended approach is to maintain a staging environment, test every update there first, then apply it to the live site once you're confident nothing breaks. That's sensible advice, but it also means every update cycle requires professional time, and the more plugins and customisations you have, the more testing each update demands.
With a bespoke site, the developer can plan application changes around a focused codebase rather than a collection of WordPress plugins. The site still depends on software and infrastructure that need updates, and changes still need testing before release.
One of WordPress's selling points is customisation. Thousands of themes. Tens of thousands of plugins. Page builders that let you drag and drop your way to any layout you want. But there's a paradox at the heart of this: the more you customise a WordPress site to match your specific needs, the more fragile it becomes.
Add custom code to a theme? It'll be wiped out by the next theme update unless you've set up a child theme properly. Use a page builder to create complex layouts? Your content becomes locked into that builder's proprietary markup. If you ever need to change themes or move away from that builder, you're looking at a significant rebuild.
Rely on a specific plugin for a critical feature? Your site now depends on that plugin's developer continuing to maintain it, keeping it compatible, and not abandoning it. The more your site deviates from a vanilla WordPress install, the more technical debt you accumulate, and the harder it becomes to maintain or evolve over time.
A purpose-built website can reduce the gap between the business requirement and the implementation. That is a design goal, not an automatic property of custom code: bespoke projects can also accumulate technical debt if changes and dependencies are poorly managed.
There's a subtler issue here that often gets overlooked: who actually controls your website?
With a WordPress theme and plugin setup, you're dependent on a chain of third parties. The theme developer decides how your site is structured. Each plugin developer decides how their functionality works, what data they store, and when they push updates. WordPress.org decides what stays in the plugin repository and what gets removed. Your hosting provider decides which PHP versions are supported and when older ones get retired.
If a theme developer stops maintaining their product, your site is stuck on an ageing codebase. If WordPress removes a plugin from the repository for security reasons, you might lose access to critical functionality. If your hosting provider upgrades PHP and one of your plugins isn't compatible, your site could go down with no fix available.
A bespoke project should make ownership, usage rights and handover arrangements explicit, including any reusable CMS code and third-party components. Agree what you receive and what another developer would need to maintain the site. Commissioning custom work does not automatically transfer copyright; see the UK guidance on ownership of commissioned works.
WordPress can be a suitable choice for business websites as well as personal projects. The decision should depend on the requirements, implementation quality, available support and total cost over time. Our preference for bespoke development is about direct control over the work, not a claim that WordPress is unsuitable for every serious business.
For a business that depends on its website, compare the ongoing costs of both options: hosting, licences where applicable, security updates, testing, support and future changes. A bespoke build has its own maintenance costs; it should not be compared with WordPress as though custom software needs none.
A bespoke website may cost more initially, but the useful comparison is what the whole solution costs and delivers over its lifetime. Performance, security and maintainability depend on how it is built and supported. Ownership and usage rights depend on the agreement, not simply on whether the code was written from scratch.
At Pedwar, this is why we build from scratch. Not because we have anything against WordPress as a project. It's an impressive piece of open-source software and it's served millions of people well. But for the businesses we work with, from solicitors and marine companies to construction firms and retail operations, the long-term cost of technical debt matters.
Our CMS lets us build features around the client's requirements rather than depending on a large collection of WordPress plugins. Keeping that codebase useful and dependable still means managing dependencies, testing changes and planning ongoing maintenance.
Our aim is a website built around the business, with performance, security, maintenance and future changes considered together. Clear documentation, agreed access and handover arrangements matter alongside the code itself.
Technical debt is invisible until it isn't. And by the time you can see it, you're already paying the interest.
We're proud to have been recognised as Wales' Most Trusted Web Design & Development Company for 2025. This award reflects our commitment to delivering exceptional digital solutions and outstanding client service that sets the standard for excellence.
