WordPress is cheaper on day one and dearer on day 800. The five-year maths of maintenance, slow pages and lost marketing speed.
A founder emailed me last month with a familiar problem. Her company's site had been built three years ago in WordPress by a freelancer who had since vanished. Page-load times had crept above six seconds. Plugin updates were stalled because two plugins now conflicted. Her latest marketing campaign was bottlenecked because the design team couldn't get a new landing page live without engineering involvement.
She asked the same question every founder asks at that stage: should we just keep patching this, or rebuild from scratch?
I do not have a religious answer to that question. There are businesses for which WordPress is correct. But the criteria most teams use to make this decision are the wrong ones. They look at the day-one price tag and assume that lower is better. The math doesn't work that way.
What WordPress actually costs you
The pitch for WordPress is straightforward and not, in itself, dishonest. You get a working site with editable content faster than you would otherwise. The first version is cheaper than custom development. The non-technical people on your team can update copy without filing a ticket.
These benefits are real. But they come paired with a set of costs that nobody adds up at the start.
The first cost is performance. By default, WordPress builds each page in PHP with database queries, and plugins add their own scripts and queries on top. Full-page caching, a CDN and careful image work can make a WordPress site fast, and WordPress's own documentation explains how (WordPress performance guide). The catch is that speed then depends on that setup being built and kept intact as plugins and themes change. In a static or server-rendered modern stack, fast pages are the default rather than something you maintain. For a marketing site whose job is conversion, that difference is not a vanity metric.
The second cost is maintenance overhead that accumulates linearly. Every plugin you install is a dependency you now have to update, monitor for security disclosures, and pray will not conflict with the next plugin. After year one, you have ten plugins. After year three, you have twenty-five. By year five, every update is a coin flip about whether the site survives. The hidden subscription here is the contractor you eventually pay, monthly or quarterly, to keep the lights on.
The third cost is flexibility. WordPress was designed for a world of post-comment-category-tag content. When your real content shape is something else, a software product with feature pages, a service business with case studies, a SaaS company with documentation, pricing tiers, integrations, you fight the platform. You install Advanced Custom Fields, Custom Post Types UI, Yoast, a page builder, and now you are running a system held together by extension points that were never designed to bear weight. Every new content type costs you a day of plugin configuration. Every refactor of an existing content type risks breaking the published site.
The fourth cost is security exposure. WordPress powers a very large share of the web, which makes it a constant target for automated attacks, and most real-world vulnerabilities come from plugins and themes. Core, plugins and themes all need regular updates. If nobody owns that patching, the risk grows every month.
When WordPress is correct
I do not want to argue that nobody should use WordPress. It is correct for specific cases.
It is correct when your site is predominantly editorial content, a magazine, a news site, a blog-first business, and the workflow advantage of having non-technical staff publish posts is the dominant requirement.
It is correct when the business itself is unlikely to scale traffic significantly, meaning that ten- or twenty-percent performance gains do not translate to meaningful revenue. A small local business with low traffic does not need sub-second LCP.
It is correct when you have deep WordPress expertise on staff, somebody who can write themes from scratch, audit plugins for quality, and maintain the platform without it becoming a sprint-killing distraction.
It is correct when the alternative is no site at all, because of budget or timeline. A live WordPress site is better than a still-being-built custom one.
Most of the businesses I talk to do not fit these criteria. They are companies whose site is the primary acquisition channel, whose traffic and conversion materially affect revenue, who do not have a WordPress expert on staff, and who could afford to do this properly if they understood the math.
The math
When clients push back on the custom-build quote, I run the same exercise. Estimate three things over five years: cost of platform maintenance, cost of marketing inefficiency, and cost of underperformance.
Maintenance is the easiest to estimate. As an illustrative scenario, not a market price: if a WordPress site needs two to four developer hours a month and you pay seventy-five euros an hour, that is €1,800 to €3,600 a year. Plug in your own hours and rate. Many companies only pay this after an incident, at an emergency rate.
Marketing inefficiency is harder to put a number on. If your team cannot ship a new landing page or page type without a developer, experiments get delayed or skipped. Estimate it for your own business: how many launches did you postpone last year, and what were they worth?
Underperformance (slow load times, broken mobile experiences, plugin glitches at conversion points) is the hardest to measure, and there is no universal conversion figure to apply. Measure it on your own site: record Core Web Vitals and the conversion rate on your key pages, fix the slowest templates, and compare. If the site is a main source of revenue, even a small, measured lift can outweigh the cost of the build over a few years (web.dev: Core Web Vitals).
The honest version of this calculation is: WordPress is usually cheaper on day one, and can become more expensive later, depending on how well it is built and maintained. Run the numbers with your own hours, rates and conversion data before you decide.
What custom actually means in 2026
The word custom used to mean bespoke everything, which was indeed expensive. It does not mean that anymore.
A modern custom site in 2026 means: a typed framework like React, Vue, or Svelte; rendered statically or on the edge for sub-second performance; integrated with a headless CMS like Sanity, Contentful, or a flat-file system for content management; deployed continuously through Vercel, Netlify, or Cloudflare; and built on a design system that engineering can extend without redesigning. The non-technical team still gets a CMS. The engineering team does not get a platform that fights them. The user gets a site that loads instantly.
The cost to build this, well, is higher than a WordPress freelance project. Operating it is usually simpler: there is no plugin stack to keep compatible. It still needs care: frameworks like Next.js ship regular security updates (Next.js releases), and dependencies have to be kept current. The difference is that updates are fewer, planned and tested, rather than a monthly gamble across dozens of third-party plugins.
The right time to switch stacks is the moment before the next plugin breaks something important. After that moment, you are paying double, once to fix the break, once to start the migration.
How to decide, today
If you are sitting on a WordPress site and wondering whether to keep going, ask yourself three questions.
First: is this site a primary acquisition channel for the business? If yes, performance and flexibility matter at scale, and you almost certainly want to migrate.
Second: can your team ship new content shapes without engineering involvement, today? If no, you are leaking marketing experiments and the platform is part of why.
Third: what happens if a critical plugin is deprecated next month? If the answer is anywhere on the spectrum between uncertain and the site goes down, that is information about how stable your foundation actually is.
If you answered yes-no-uncertain or some variant, the math is going to recommend rebuilding. The longer you postpone it, the worse the migration gets, because every plugin you add and every custom post type you create is another thing to translate to the new system. The cheapest migration is the one you start today.
The expensive one is the one you start the month the platform finally fails. Most companies migrate at that point, not earlier, and they pay for both the failure and the rebuild simultaneously. There is a better order of operations.
Frequently asked questions
Is a custom website better than WordPress?
For companies whose website is a main source of new business, usually yes: a modern custom build loads faster, needs no plugin maintenance and adapts to your content. WordPress remains a good choice for editorial sites or low-traffic businesses.
How much does WordPress maintenance cost per year?
It depends on the number of plugins, traffic and how critical the site is. As an illustration, two to four developer hours a month at €75 an hour is about €1,800 to €3,600 a year. Use your own hours and rate.
When should I move away from WordPress?
When the site is a primary acquisition channel, when your team can't publish new page types without a developer, or when a single plugin failure could take the site down.
