Every plugin is a subscription your client will forget to renew

A plugin looks like the cheap option at the moment you're deciding. Ten minutes of configuration instead of two days of building, and a line in the estimate that goes down. Everybody's happy at that meeting.

The cost turns up later, spread across several years, and lands on somebody who wasn't in the room: usually the client, occasionally the studio, always at a bad moment.

Three costs, none of them the purchase price

The licence renews, on a card, belonging to a person. It renews every year, the card expires, and the person may have left the company. Nobody has told the accounts department what this £59 charge is for, so at some point it gets queried and cancelled.

The failure isn't dramatic. The site doesn't break. Updates stop arriving while everything continues to look fine, and the first anyone knows is when a vulnerability is disclosed for a version you're still running.

It gates your upgrade path. A site is only as upgradable as its least-maintained dependency. One abandoned plugin can hold a site on an old major version for a year or more, which is how sites end up stuck rather than merely out of date.

And you don't find out until you attempt the upgrade, which is usually the moment you least want a surprise.

It's code you didn't read, running with database access. Most plugins are written carefully by people who care about their work. You're still inheriting every decision that developer makes from now on, including the decision to stop, to sell it to somebody else, or to add analytics in a minor release.

The scale of it, in the neighbouring ecosystem

Craft's plugin ecosystem is too small for anyone to publish meaningful vulnerability statistics about. WordPress's isn't, and it's the clearest evidence available for what happens when dependency count grows.

Patchstack recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, up 42% on the year before. 91% were in plugins. WordPress core itself accounted for six.1

The risk is the third-party code stacked on top of the platform, and every plugin adds to it.

The figure that should concern anyone offering a support retainer: 46% of those vulnerabilities had no patch available when they were publicly disclosed.1 For that window, knowing is all you can do. The only reliable mitigation is not having installed it.

What we do pay for

We're not purists about this. A site with zero plugins would be a worse site built by people making a point.

We pay for plugins where the problem is hard, the plugin is actively maintained by someone with a track record, and our version would be measurably worse. In practice that means SEO field management, asset handling and image transforms, and a small number of first-party tools where the alternative is reimplementing something Craft's own team maintains.

Rebuilding image transform handling badly would be worse for everyone, and we'd be doing it to satisfy a principle rather than to help anybody.

What we write instead

Anything small enough that the plugin is mostly configuration wrapped around fifty lines of logic. Anything that exists purely to add one field type. Anything whose main job is to render markup we'd have to override completely anyway, so we'd be carrying the dependency and writing the code.

And anything that would be the fourth plugin doing roughly the same category of work. Four plugins with overlapping responsibilities is worse than one piece of custom code, because now there's an ordering problem nobody documented.

If integrating the plugin takes longer than writing the thing, the plugin isn't saving anyone time.

The two questions we ask before installing anything

First: will this plausibly still be maintained in three years? Look at the release history, not the marketing. A plugin updated last week by someone who's been shipping for five years is a different proposition from one that had a burst of activity in 2023.

Second, and more important: if it isn't maintained, how hard is it to remove? If removing it means unpicking content structure (it defined field types, stored data in its own tables, or shaped how entries relate to each other), the answer is no, however good it is today.

Content structure is the expensive thing to change. Anything that owns part of it needs to be something you're prepared to live with permanently.

The exception

Sometimes a client already runs a plugin, has built a process around it, and moving away would cost them more than keeping it costs us. We keep it, we document the risk, and we say so in writing.

Purity isn't the aim. Every one of these should be a decision somebody made on purpose, rather than an accumulation nobody noticed.

What the client notices

Nothing, which is the aim. Their annual renewal list stays short and their upgrade path stays open. Nobody has to explain why the site can't move to the next major version until a third party they've never heard of ships a release.

An invisible benefit is hard to sell and easy to skip. It's also the difference between a site that's still straightforward to work on in year four and one that everyone has started calling legacy.