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. A plugin written for a single site interests nobody.

A custom plugin is not secure by definition: it is if it uses nonces, checks capabilities, sanitises input and runs prepared queries. But it drastically reduces the amount of exposed 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 releases, vulnerability history (and how quickly issues 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 admin 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: generic plugins almost always get 70% of the way and the remaining 30% becomes a patch.

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;
• no page builder: the native block editor, with custom blocks where needed, is enough and leaves no proprietary markup in the database;
• 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.

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: I have been programming since 1999, delivered more than 300 projects and worked as an external developer with about 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.