The hidden cost of plugins

The studio’s most expensive recent project, on a per-hour basis of unpaid maintenance, was a WordPress site we shipped two years ago, on a budget that did not include ongoing maintenance, with seventeen plugins the client asked us to install.

Every plugin is a piece of software the studio is responsible for, even if it did not write any of it. The plugin will need updating. The update will sometimes break a different plugin. The breakage will sometimes happen on a Friday afternoon. The breakage will, occasionally, be the studio’s fault for not testing the update locally, and will, more often, be the plugin author’s fault for shipping a regression they did not catch. The fix, in either case, is the studio’s problem.

A few rules the studio has settled on.

Each plugin needs a justification stronger than “it does the thing we need”. The justification should be: this plugin does the thing we need, and we cannot reasonably ship the same functionality with code we control. If the second clause is not true, the studio writes the code.

For the plugins the studio does install, prefer plugins from authors with a track record of shipping bug fixes within a week. Most plugin disasters are not the plugin’s initial code; they are the plugin’s authors disappearing for six months while a security advisory sits open.

The studio now ships sites with the smallest plugin set it can justify. Most marketing sites can run on a CMS plus zero plugins, if the CMS is well-chosen. The Webflow and Squarespace sites we have shipped have zero plugins because the platforms do not support them, and the sites are easier to maintain than the WordPress sites with seventeen.

This sounds anti-WordPress. It is partly anti-WordPress, but the same logic applies to Shopify apps, Webflow apps, Figma plugins, VS Code extensions, and npm dependencies. The hidden cost of every “free” plugin is the cost of running it for as long as the studio is responsible for the project, which, for small-business clients, is usually years.

A useful exercise: for each plugin or app on the studio’s last shipped site, ask what the per-year maintenance cost has been. Studios that do this honestly tend to ship the next site with half as many plugins.

There is a related point about npm dependencies in front-end builds, which deserves its own post. The short version: the studio’s default build now uses a dozen dependencies, not a hundred. The build is faster, the security advisories are quieter, and the resulting site is, in almost every measurable way, better.

The plugins that are worth keeping are the ones that solve a specific problem the studio cannot solve as well in code. There are not very many of these. Most of the plugin ecosystem is, on a five-year timescale, technical debt being sold as convenience.

The companion post on Figma plugins worth keeping covers the same logic for design tooling. The npm dependency audit guide is the canonical reference for the same exercise on the JavaScript side. Mark Pilgrim’s old “Why I Won’t Buy a Mac” is older than this post and points at the same underlying problem about software you do not control.