Every plugin is a subscription your client will forget to renew
Plugins aren't free code. They're a licence, an upgrade path and a security surface, and somebody has to own all three for the life of the site.
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 rather than up. Everybody's happy at that meeting.
The cost turns up later, distributed across several years, and lands on somebody who wasn't in the room. Usually the client, occasionally the studio, always at an inconvenient moment.
Three costs, none of them the purchase price
The licence renews, on a card, belonging to a person. Every year. That card expires. That 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 mode here isn't dramatic. The site doesn't break. Updates simply stop arriving while everything continues to look completely 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 genuinely 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 are nonetheless 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.
What we do pay for
We're not purists about this, and a site with zero plugins would be a worse site built by people making a point.
We pay for plugins where the problem is genuinely 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 involved, and we'd be doing it to satisfy a principle rather than to serve 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, which means we're 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 this to remove? If removing it means unpicking content structure — if it defined field types, or stored data in its own tables, or shaped how entries relate to each other — then the answer is no, regardless of how 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 worth naming
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.
The point isn't purity. It's that every one of these should be a decision somebody made deliberately, rather than an accumulation nobody noticed.
What the client notices
Nothing at all, which is precisely the point. Their annual renewal list stays short. Their upgrade path stays open. Nobody ever has to explain why the site can't move to the next major version until a third party they've never heard of decides to ship a release.
It's an invisible benefit, which makes it a difficult thing to sell and an easy thing 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 quietly started describing as legacy.