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.
This isn't a theoretical risk. In December 2025 alone, over 150 plugins were removed from the official WordPress repository due to unpatched security issues or developer inactivity. These "zombie plugins" sit on thousands of live websites, permanently exposed to known vulnerabilities, with no fix ever coming.
If your site depends on one of these abandoned plugins for core functionality, such as a booking system, a particular form handler, or a custom integration, you're in serious trouble. You can't update it. You can't easily replace it without rebuilding whatever it was doing. And every day it stays installed, your site is exposed.
According to Patchstack's 2026 State of WordPress Security report, 11,334 new security vulnerabilities were found across the WordPress ecosystem in 2025. That's not a typo. Over eleven thousand new vulnerabilities in a single year, and more high-severity ones than in the previous two years combined.
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.
A separate analysis from Developress found that 92% of all successful WordPress breaches in 2025 originated from plugins and themes rather than from the core software. Brute-force attacks rose 45% over the course of the year, increasingly powered by AI-enhanced botnets.
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.
When you build a website from scratch, none of this applies. There are no third-party plugins to be exploited. No theme vulnerabilities to be discovered. No dependency chain where a single unpatched component can compromise the entire site. The attack surface shrinks dramatically because the codebase contains only what was deliberately written for that specific website.
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 website doesn't have this problem because it doesn't have the bloat in the first place. When every line of CSS, every JavaScript function, and every database query is written specifically for that site, there's nothing to strip out or compensate for. The result is a leaner, faster site that doesn't need a stack of optimisation tools to perform well.
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 built on a proprietary CMS, the developer controls the entire stack. There's no theme that might release an incompatible update. No collection of plugins from different authors all pushing changes at different times. Updates happen deliberately, tested against a codebase the developer understands completely because they wrote it.
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.
This is the opposite of what happens when a site is purpose-built. A bespoke website has no gap between what it was designed to do and what it actually does. There's no theme loaded with 50 features when you only need three. No page builder adding layers of abstraction between you and your content. No plugin doing 80% of things you don't need in order to deliver the 20% you do.
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.
When a website is built from scratch by a developer you work with directly, you own the code. Not a licence to use someone else's code. Not a theme you've customised. The actual source code, written for your business, maintained by someone who understands every line of it. That's a fundamentally different relationship, and it's one that gives you far more control over your digital presence.
It would be dishonest to pretend WordPress is never the right choice. For personal blogs, hobby projects, or situations where budget is extremely tight and the site's role is non-critical, WordPress with a well-chosen theme can be a perfectly reasonable option. It gets something online quickly and cheaply, and for some people, that's exactly what's needed.
But for a business that depends on its website, where performance affects revenue, where security protects client data, where the site needs to evolve as the business grows, the calculus changes. The upfront saving of using a theme and plugins gets gradually consumed by the ongoing cost of managing the technical debt they introduce. Slower load times. Security patches. Plugin conflicts. Compatibility testing. The fear of hitting the update button.
A bespoke website costs more at the start. There's no getting around that. But it arrives without the hidden freight of code you don't need, dependencies you can't control, and compromises that compound over time. It's faster because it's lean. It's more secure because its attack surface is smaller. It's easier to maintain because one person or team understands the entire codebase. And it's yours, fully, without conditions.
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 proprietary CMS is built to do exactly what each client needs, nothing more and nothing less. There are no unused features bloating the codebase. No third-party plugins creating security vulnerabilities or performance bottlenecks. No update treadmill where a change to one component threatens to break everything else.
When we build a website, the client gets a site that's fast from day one and stays fast. A site that's secure because there's no ecosystem of third-party code to exploit. A site that can be updated and extended without the anxiety of wondering what might break. And a site they genuinely own, built specifically for their business and maintained by the people who wrote every line of it.
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.
He is able to understand what I want and need from AI and IT in general. I have established a trusted and supportive relationship with him and I can't recommend him more than I do. He explains what he is doing and delivers what is needed.