WordPress or Custom Build? Run the Five-Year Numbers

WordPress is not widespread because everyone missed something. According to W3Techs, 40.7 per cent of all websites and 58.9 per cent of websites with a known content management system run on WordPress (as of 9 September 2026). That is not an accident, and not marketing alone. It is the result of twenty years of genuine strengths. Anyone dismissing WordPress wholesale in order to sell something else is arguing dishonestly.

What WordPress genuinely does better

Three things WordPress does better than almost any custom build, and none of them are trivial.

First, editorial work. Multiple people, roles and permissions, a preview mode, revisions: if you publish daily, you only get that elsewhere with real effort.

Second, the market. There is someone in every German town who knows WordPress. That is real protection against dependency: you can change provider without rebuilding the site. No custom build offers that.

Third, off-the-shelf functionality. Shop, membership area, booking, multilingual setups: a mature extension exists for nearly everything. If your requirement is standard, a standard solution is the sensible answer. That is also the core argument of our article on off-the-shelf software versus a custom web app.

The costs that never appear in the quote

With WordPress, the build price is rarely the issue. The recurring items are.

Updates. Core, theme and every plugin are updated regularly. Any update can shift something, so testing is part of the job. Skipping it saves money right up to the day it does not.

Security. Attacks on WordPress almost never target the core. They target known holes in extensions that have been open for months. The protection is mundane and still rare: update promptly, install little, remove what you do not use.

Loading speed. A theme that can do everything loads everything. Add plugins that inject their own scripts and stylesheets on every page. What that means for your measurements is covered in the article on Core Web Vitals.

Dependencies. A plugin whose developer stops is not a small problem. It is a function of your website that will never receive a security update again.

Where WordPress runs into technical limits

The limit rarely sits where people expect it. It is not design and it is not content. It is how much control you need over what gets delivered to the browser.

If you want to generate hundreds of structured pages from one data source, if you need bespoke JSON-LD per page type, if your site contains a genuine application, or if loading speed is a selling point against your competitors, you end up working against WordPress rather than with it. One option sitting between the two worlds is described in the article on headless CMS: WordPress stays the editing tool, while a separate build handles delivery.

The host decides more than most people assume

On WordPress, loading speed and security depend substantially on hosting, and that is where people most often save at the wrong end. A cheap shared plan splits computing power with hundreds of other installations, keeps old PHP versions around longer and leaves you alone with updates.

Managed hosting costs more per month and in return handles server-side caching, automated backups with a restore point, a staging environment for updates and current PHP versions. In practice, the gap between those two is larger than the gap between two themes. So if you take the maintenance question seriously, settle it at the hosting layer first and only then at the extension layer.

The honest decision rule

Do not price the build, price five years. On the WordPress side sit hosting, a maintenance agreement or your own time, licences for premium extensions, and a buffer for the day an update breaks something. On the custom side sits a higher initial investment and considerably less movement afterwards.

If you publish a lot and want to be able to switch provider at any point, WordPress plus dependable maintenance and security is a sound position. If you want a site with a defined scope that is fast and does not demand weekly attention, you pay more once and less afterwards.

Concrete steps for the next 90 days

• Days 1-15: list every active plugin, noting the last update and the developer for each
• Days 16-30: deactivate and remove anything without a demonstrable job. This is the single most effective step
• Days 31-45: put update responsibility in writing. Who applies updates, on what rhythm, with which backup taken first
• Days 46-60: measure loading speed on a phone over mobile data and name the three biggest brakes
• Days 61-90: build the five-year total - hosting, maintenance, licences, your own time - and hold it against a quote for a custom build

Conclusion

WordPress is the right choice for a great many companies, and its market share is an argument in its favour, not an accusation. It is simply not a tool you set up and leave alone: the price of flexibility is maintenance, and that price is real. Companies that guarantee the maintenance do well with it. Companies unwilling to fund it should know that before deciding, not after the first incident. How a migration runs without losing rankings is covered in the article on website relaunches.