WordPress is a publishing platform with a vast market of ready-made extensions and themes. The decision about it is not a choice of technology for a site. It is a ruling on how much responsibility an organisation takes for code it did not write and whose release cycle it does not control. The bill arrives over years, not at launch.
Quick Overview
What this article covers:
- The cost carried in a site before anyone proposes changing the platform
- The conditions that must hold together for such a platform to be right
- The situations in which it does not address the real problem
- The alternatives that remain and the price attached to each
- The commitment signed when a site rests on somebody else’s extensions
Who this article is for:
- People accountable for corporate communication and the company site
- Leads of teams maintaining an organisation’s presence online
- Managers planning rollout and maintenance budgets
The Cost of a Site Where Each Content Change Needs a Developer
The bill does not start with the name of a platform. It starts with items nobody books separately: a ticket to fix a typo queued behind releases, a campaign pushed back because nobody can add a page, and content published wherever it fits rather than where it belongs. Each item is minor alone. Together they form a standing line in the cost of communication.
A further cost appears when people change roles. A site built without an editorial layer is understood solely by whoever built it, and the successor begins by reconstructing somebody else’s decisions. The organisation then defers changes exactly where communication is needed — and that deferral, not the site, is the real expense.
The problem has variants, and confusing them is what costs the most. The first is throughput: publishing is the bottleneck because it requires a release. The second is scope: functions are needed that nobody in-house wants to write from scratch — forms, multilingual content, a shop, an events calendar. The third is responsibility: the site already exists, but nobody can say who owns its updates or what happens once it stops working. The ruling does not depend on how technically advanced the team is — it depends on which variant the organisation is actually paying for.
Conditions That Make a Platform With an Extension Ecosystem the Right Answer
A platform with an ecosystem of its own is the right answer when three conditions hold together, and not when any of them holds on its own:
- Content changes more often than code. The editorial team publishes regularly and wants to do so without a developer. Where the site is a business card refreshed once a season, that layer is a cost with no use.
- The functions needed are market-standard. Forms, catalogues, multilingual content and sales exist as ready-made extensions, so the organisation pays for configuration instead of construction. Where the need is unusual, that advantage disappears in the opening week.
- The organisation accepts running updates as a process. The core, the theme and the extensions each have their own releases and security fixes. A team that does not plan for this ends up with a site updated only after an incident.
Only when these conditions hold together does working on the platform itself begin to pay: performance, a theme that survives a core update, and extensions written for the organisation’s process rather than bought blind. That scope — through to measurable optimisation — is covered by the Advanced WordPress: optimization and extension training.
Situations Where This Platform Is the Wrong Answer
The commonest error is reaching for this platform because “everybody uses it”, before anyone has named what the site is supposed to do. The organisation then gets an installation hung with extensions nobody chose deliberately, and a bill for maintaining each of them.
Beyond that, there are situations where it does not address the real problem. A site that is in truth an application — with a data model, business logic and integrations of its own — will have it bent around the assumptions of a publishing system, and each core update becomes a regression risk in logic never meant to live there. Regulatory requirements around personal data or payments move the burden of proof onto the organisation, while its attack surface grows with each extension from an unknown author. A team without a maintenance plan gets a site that works until the first version mismatch; on a platform with this market share, public vulnerabilities are known sooner than anyone reacts. None of this is altered by how much work already went into the rollout. What that attack surface means on the application side is set out in the article on network, web and mobile application security.
Alternatives and What Each One Costs
A static site generator produces a site with no database and no execution layer, so the attack surface nearly disappears and maintenance falls back to file hosting. The price is publishing that passes through a build: the editorial team works in a tool somebody has to provide, and each change requires a run. A headless system separates content from presentation and can feed an application and a site at once, but the organisation then maintains content and presentation apart, and loses the pre-publication preview unless it builds one. A low-code platform shortens the route to something working and moves maintenance to the supplier, at the cost of dependence on that supplier’s pricing and limits. How much can be handled that way is set out in the discussion of low-code and no-code platforms.
The last route is the cheapest and the least often weighed: leaving the platform alone and fixing the process — editorial permissions, content review and an update schedule. It is also sometimes the only one that works, because the others assume the tool is the problem.
The Long-Term Bill of Building on Someone Else’s Extensions
What is signed first is somebody else’s release cycle. The core, the theme and each extension have separate authors, separate rates of repair and separate moments of abandonment. An unmaintained extension does not stop working overnight — it stops receiving fixes, and that surfaces only at the next core update or at an incident.
What is signed next is an obligation to test updates that nobody plans for in advance. The site needs a copy for checking releases, a backup whose restore has been rehearsed, and knowledge of which extensions are critical to business processes. The dearest item, however, is none of these; it is competence on the organisation’s side. A site run by a single person turns each change into a queue for a single calendar and each absence into a risk. The capability that lowers this bill is an editorial team able to run the site unaided — the scope of WordPress: creating and managing websites. Without it, an organisation pays twice over: for the rollout, and separately for each change it cannot make itself.
FAQ — Frequently Asked Questions
Is a large supply of ready-made extensions an advantage or a risk?
An advantage at rollout and a risk in maintenance — these readings do not exclude each other. The rule decides: an extension enters when a named person owns its updates and knows what happens once it is removed. Without such a rule, the count of extensions grows on its own.
Is migrating away from this platform expensive?
Content moves easily, because it is structured. The cost lies in the functions the extensions brought: forms, redirects, multilingual content and integrations have to be rebuilt on the other side, and part of them was never written down. A migration decision is therefore taken on an inventory of extensions, not on the volume of content.
How can it be told that a site has slipped out of control?
By the fact that nobody can say what a given extension does or who switched it on. Updates are deferred because nobody knows what will break after them. That is the moment for an inventory and a ruling on scope, not for another extension patching the effects of the previous one.