Most WordPress quotes are honest about year one and quiet about years two through five. That is where the money is. A site built on a plugin stack is not a purchase, it is a subscription to roughly twenty other companies' software. What follows is the method: cost categories, multipliers, and a sixty-month comparison you can run on your own numbers. It includes the part most agencies avoid saying: WordPress is often the cheaper answer.
What does a WordPress site actually cost over five years?
It costs the build, plus sixty months of licences, hosting and human attention. On a working business site the recurring half commonly overtakes the original build cost somewhere between year two and year three. The build is the small number. The subscription tail is the real bill, and it compounds.
- ▸First-year pricing is not renewal pricing. Introductory discounts are an acquisition tactic. Budget renewals at list price, and check whether the vendor has moved to annual-only or per-site terms since you bought.
- ▸Plugin count only goes up. Every new marketing requirement arrives as a plugin, and each adds a licence, an update surface, a conflict candidate and weight on every page load.
- ▸Hosting is tiered on the things that grow. Visits, storage, PHP workers. The tier that quotes well in month one is rarely the tier you are on in month forty.
The cost categories nobody puts in the quote
Seven categories drive the number: premium theme, page builder, plugin licences, managed hosting and CDN, backup and security subscriptions, transactional email, and human time. A typical proposal prices the first two properly, mentions hosting, and goes quiet on the rest.
- ▸Premium theme licence. Annual, and it buys updates. The theme keeps running if you stop paying, but it stops receiving security patches, which is the thing you were actually buying.
- ▸Page builder licence. The fee is modest. The structural cost is lock-in, because builder content is stored as builder markup, so leaving means rebuilding pages rather than exporting them.
- ▸Plugin licences. Forms, SEO, membership, booking, multilingual, caching, custom fields, image optimisation, consent. Ten to twenty-five on an active site is unremarkable. Count yours today, then what you had two years ago.
- ▸Managed hosting and CDN. The largest recurring line for most sites, and the one that steps upward without warning when a campaign lands.
- ▸Backup and security subscriptions. Off-site backups, malware scanning, a firewall, uptime monitoring, usually separate vendors and invoices.
- ▸Transactional email. Once the host's PHP mail stops landing in inboxes, order confirmations move to an external provider with its own fee.
- ▸Human time. The retainer, the emergency call-out, and hours your staff spend testing after updates. Usually the biggest number, and the one nobody writes down.
The five-year method you can run on your own numbers
Build a sixty-month table with four columns: one-time costs, annual recurring at renewal price, an escalation assumption, and hours of human attention at your real blended rate. Run it twice, once for the plugin stack and once for a custom build, then compare totals and risk rather than feelings.
1. List every licence at renewal price, not what you paid in year one. Open each vendor's pricing page today. 2. Apply an escalation. Low-to-mid single digits per year is defensible, but verify each vendor's own history rather than a generic figure. 3. Add plugin drift. Two to four new plugins a year is typical on an active site. Price the licences and the extra testing time. 4. Step the hosting tier at least once across the period, more if you expect traffic growth. 5. Price human time honestly: monthly hours for updates, staging tests, fixes and content support, times your real cost per hour. 6. Add an incident allowance. One compromise or one badly broken update in five years is planning, not pessimism. 7. Add exit cost to both columns. Builder-locked content and undocumented custom code are both expensive exits, and this step usually decides the argument.
For the same discipline applied to bespoke software rather than a website, see Custom Software Is Also a Subscription, to Yourself: The Honest Year-Two Ledger.
Where a custom build hides its costs
A custom site trades recurring licences for a bigger day-one cheque and a smaller but real ongoing bill: hosting, a dependency update cadence, and someone who understands the codebase. Anyone selling build-once-pay-nothing is either omitting maintenance or planning to be gone before it matters.
- ▸The build. Dominated by design, content modelling and integrations, not lines of code. For how those figures are constructed, see How Much Does It Cost to Build Custom Software in 2026?
- ▸Hosting. A statically generated or server-rendered site sits at the cheap end, because there is no persistent PHP process per request and pages serve from a CDN edge.
- ▸Dependency maintenance. Framework and library updates on a cadence, plus urgent patches. Cheaper than plugin roulette because you control what is installed, but never zero. Same mechanism as Supply Chain Attacks: Why Your Dependencies Are Your Biggest Risk.
- ▸The bus factor. The genuine risk. Insist on written handover, a runnable local setup, and a deployment someone other than the author has executed.
- ▸Content editing. Budget a hosted headless CMS seat, or the cost of self-hosting one.
The breakage tax: updates, conflicts and the retainer
The largest untracked line on a five-year sheet is human time spent restoring a site after an update. Core, theme and every plugin ship on independent schedules from independent vendors, and all of it executes inside one PHP process. Conflicts are a structural property of that arrangement, not bad luck.
- ▸Plugins hook the same actions, enqueue different versions of the same library and write to the same options table. One vendor changing a hook priority breaks something owned by another vendor.
- ▸The expensive part is discovery, not the fix. Nobody tells you the contact form silently stopped delivering. You learn it when a customer complains weeks later and the leads are gone.
- ▸The mitigation is engineering practice: staging, update rehearsal, tested rollback, and monitoring on things that earn money such as form submissions and orders, not just uptime pings.
- ▸Deferring updates trades breakage risk for security risk, so the stack punishes both choices. That tension is what the retainer buys down.
This is the general pattern of assembled software, examined further in Low-Code vs Custom Code: When Cheap Tools Cost You More Later.
Security is a cost category, not a checkbox
WordPress powers a very large share of the web, which makes it the most economically attractive target class in existence. The core project is not usually the problem. The plugin ecosystem is: thousands of independent vendors, wildly varying code quality, and a disclosure-to-mass-exploitation window commonly reported in hours.
- ▸Missing capability checks on REST or admin-ajax handlers, letting an unauthenticated request perform an administrator action.
- ▸Arbitrary file upload in plugins handling media, imports or form attachments without validating type and destination.
- ▸Unsanitised input reaching SQL, still routinely found in older or abandoned code.
- ▸Stored cross-site scripting in settings pages, turning one low-privilege account into administrator access the next time an admin loads that screen.
- ▸Version fingerprinting. Scanners read plugin versions from public asset URLs, then spray known exploits across the internet. Nobody targets you specifically, and obscurity is not a control.
The sharpest edge is abandoned plugins: code whose author stopped shipping still runs and still carries the flaw, so remediation means deleting a feature the business depends on. Verify each plugin yourself: last update date, support forum activity, and any listing in public vulnerability databases. Make it a monthly inventory.
When WordPress is genuinely the cheaper answer
Often, and any consultancy that will not say so is selling. If your site is content-led, changes weekly, carries no custom business logic, and someone in-house is comfortable in the admin, WordPress will very likely beat a custom build over five years. Stay, and harden it.
- ▸Editorial and marketing sites where the value is publishing volume, not application behaviour.
- ▸No engineering access. A custom site nobody can maintain is worse than a WordPress site with a competent agency behind it.
- ▸Short horizons. An eighteen-month campaign microsite should not amortise a build over a life it will never have.
- ▸Existing team fluency. Retraining marketing staff is a real cost that never appears in the comparison.
The maths flips when the site stops being a site: plugin count climbing with every update needing a staging rehearsal, application work such as quoting, booking or live ERP integration, compliance evidence a plugin stack cannot produce, or a retainer that is now a part-time salary buying pure maintenance.
The decision rule
Do not decide on ideology. Run both columns for sixty months, add exit cost to both, then compare total spend plus the risk each option carries. If the totals land within roughly twenty percent of each other, stay where you are, because migration risk is not worth a rounding error.
- ▸If custom wins by a wide margin, the driver is almost always plugin count plus retainer hours, not hosting. Check you have not mispriced discipline that would fix WordPress anyway.
- ▸If WordPress wins, commit properly: fewer plugins, maintained vendors only, a staging environment, backups you have restored from, and a written monthly routine.
- ▸Either way, record your assumptions and revisit annually, because the plugin count changes and so does the answer.
This is the same evaluation shape as any platform decision, and the framework in Build vs Buy: When to Use SaaS and When to Build Custom Software transfers directly.
How TuniCyberLabs helps
We run the sixty-month sheet with you before quoting anything, including the times it ends in a recommendation to keep WordPress and harden it. When custom is right, we build sites you own outright: your source code, your hosting, documented handover, no per-site licences. Our services page covers the wider work.
Send us what your current stack costs and we will run the comparison with you: talk to our team.