Custom or ready-made WordPress themes and plugins? The real cost is in the dependencies

"Ready-made or custom theme?" is almost always asked in terms of upfront price, and it is almost always the wrong question. The same goes for plugins. The real cost of a WordPress site is not the theme or any single plugin, but the dependency graph built around them: who updates what, when, and what breaks as a result.

The problem is not the theme, it's the coupling

A commercial multipurpose theme is a product designed to sell to as many people as possible. To do that it bundles a page builder, dozens of layouts, a slider, often its own options framework, and "recommends" (that is, requires) a handful of companion plugins.

The technical result is tight coupling:

• content tied to the theme: proprietary builder shortcodes and meta end up in post_content. Switching theme leaves pages full of [vc_row] or markup nothing can interpret;
• chained updates: the theme depends on a builder version, the builder on a PHP version, an add-on on both. One update out of sequence and the layout breaks;
• global assets: CSS and JavaScript for features the site does not use are loaded on every page, because the theme cannot know what you will use.

Plugins do the same thing on a smaller scale. Each one adds hooks on init, wp_head and the_content, options in the wp_options table (often autoloaded, meaning loaded on every request), sometimes its own tables that nobody cleans up on uninstall.

Attack surface: the underrated part

Most WordPress vulnerabilities are not in core, which is mature and well looked after, but in the ecosystem of plugins and themes. Every third-party component is code you did not write, updated on a schedule you do not control, sometimes abandoned by its author.

There are two concrete consequences:

1. more components, more exposure windows: between a vulnerability being disclosed and the site actually being updated, days or weeks go by. With thirty plugins, those windows overlap almost constantly;
2. popular components are better targets: a flaw in a plugin installed on millions of sites justifies an automated scanner. Even a plugin written for a single site can be hit by generic scans or a targeted attack: low diffusion is not a security measure.

A custom plugin is not secure by definition: it requires capability checks, input validation, output escaping, parametrised queries and CSRF protection where relevant. These controls reduce the risk without guaranteeing the absence of vulnerabilities. It can reduce the exposed code if the scope is limited, but security must also be verified on the custom code.

When ready-made is the right choice

Ready-made makes sense, and I say this without irony, when:

• the site is simple, the budget is tight and its expected life is short (an event, a market test);
• the feature is standard and well solved by a mature, maintained plugin: forms, SEO, caching, basic e-commerce;
• the plugin does one thing and does it well, with a recognisable author and a steady release history.

Before installing a ready-made plugin I always check three things: date and frequency of the last release, vulnerability history (and how quickly they were closed), and what it loads on the front end of a page that does not use it.

When custom really pays off

Custom pays off when:

• there is a design to respect, perhaps in Figma: forcing a multipurpose theme costs more than writing the templates (I cover this in From Figma to WordPress);
• the content is structured: listings, events, catalogues. Custom post types, fields and blocks designed for that data keep the panel tidy and the front end light;
• three or four plugins exist to do one thing: a single plugin written for that purpose weighs less and is easier to maintain;
• an integration is needed with an ERP, a CRM or an external API: it must be checked whether the existing plugin covers errors, limits, reconciliation and specific cases, without resorting to fragile customisations.

How I build a custom theme

A custom theme, as I mean it, is a block or hybrid theme with very few dependencies:

• templates and blocks written for the real content, with theme.json for colours, typography and spacing, so the editor only offers choices consistent with the design;
• native block editor, with custom blocks where needed. Blocks serialise markup and attributes into the content: a compatibility strategy is needed when they change or are removed;
• assets loaded only where needed, registered per block;
• fields and content types registered in a plugin separate from the theme, so the data survives a future change of look;
• Git repository, staging environment and documentation, so whoever comes next can work on it without guessing.

I built the Dotcampus site in block-based WordPress exactly like this: pages made of reusable blocks that the client manages without touching code and without being able to break the layout. Sagre Autentiche sits at the opposite end in complexity, with a map, APIs and user dashboards, but the rule is the same: hand-written code, few third-party components.

A practical rule for plugins

For each plugin I ask myself: if the author abandoned it tomorrow, how much would it cost to replace? If the answer is "not much", a ready-made one is fine. If it is "I'd have to rebuild half the site", that plugin is a structural dependency and deserves the same care you would put into choosing a supplier.

The security checklist for custom code

For an administrative action I check authentication and capabilities, then CSRF protection where relevant. The nonce does not replace authorisation. Inputs are validated against the data domain; sanitisation normalises the value where needed, while escaping must be applied in the output context. Queries use parameters and REST endpoints declare permission checks.

For uploads I check type, size, destination and executability, without trusting the file name alone. I log errors without copying passwords, tokens or unnecessary personal data into the logs.

The review includes dependencies, updates and the possibility of replacement. A small, little-used plugin can contain a serious vulnerability: the advantage of custom code must be demonstrated in the code and in its maintenance.

Reference: nonces and authorisation, WordPress.

My take

I love WordPress: I have worked with it for years, built projects I am proud of with it, and for many sites it remains the most sensible choice. But in recent years I have watched the way it is used get worse. Themes that do everything, a plugin for every need, sites where everything is tied to everything else and a single update can bring the house down. Meanwhile automated attacks have grown, and every extra component is one more door.

That is why, when I do WordPress, I keep it lean: custom theme, few plugins chosen one by one, my own code where it matters. And that is why, when a project does not really need a dynamic admin panel, I increasingly suggest moving to something else.

Why work with me

I have been writing WordPress themes and plugins for many years: since 1999 I have delivered more than 300 projects, with more than 30 agencies, from Rome and remotely.

If you are weighing whether to keep, slim down or rebuild a theme or a set of plugins, get in touch: in a call of about 20 minutes I will tell you plainly where the risk is and what to touch first. Service details are in Custom WordPress themes and Custom WordPress plugins.