Most add-on decisions are made in about eleven minutes. Someone needs a booking form, a comparison of three plugins gets skimmed, the one with the nicest screenshots wins, and it is installed before lunch. The comparison covered features and price, which are the two things easiest to compare and the two least likely to be what the decision costs you.
The cost that matters arrives later, in instalments: every add-on becomes a permanent line item in someone's update routine, a dependency you have to test around, a renewal you have to remember, and eventually a migration you have to survive. This is a criteria-first way to judge that cost before you install, using signals you can actually check.
Everything below applies to any platform's add-on ecosystem. The examples use website plugins because that is where the pattern is most visible and most expensive.
Start with the on-ramp: do you need it at all?
Before comparing options, spend five minutes on the question that eliminates the decision entirely.
- Does the platform already do this? A surprising share of installed add-ons duplicate something the core product or the theme added two versions ago.
- Is this a one-off or a recurring need? A task you will do twice does not justify a permanent dependency.
- Would a manual process be honestly fine for now? A shared inbox instead of a help desk, a spreadsheet instead of a dashboard. Sometimes the correct answer, and saying so is the cheapest decision available.
An add-on you did not install has a total cost of ownership of zero. Nothing else on this page beats that.
Seven criteria, and how to check each
If you do need one, judge the candidates on these before you look at the feature matrix. Each has a check you can perform in a couple of minutes.
1. Maintenance cadence. Is this thing actively maintained, or is it coasting? How to check: on a public directory listing, the last-updated date and the version of the platform it declares compatibility with. A gap of a year on either is a real signal. In a commercial vendor's case, the public changelog serves the same purpose — a changelog with dated entries running to last month tells you more than any feature list.
2. Support behaviour. Not "is there support" — everyone claims support — but what happens when someone asks. How to check: public support forums, where the ratio of resolved to open threads over recent months is often displayed. For commercial products, read the last twenty support threads or reviews and look at reply times and tone, not star ratings.
3. Ownership stability. Add-ons get sold. New owners change pricing, change the licence model, or quietly stop developing. How to check: the changelog and the vendor's own blog. A recent ownership change is not disqualifying; it is a reason to check whether the release cadence survived it.
4. Data footprint — the exit cost. This is the criterion people skip and regret. Where does the add-on put your data, and what happens to it if you remove the add-on? How to check: the documentation, searched for "uninstall" and "export". Ask three questions: does it create its own storage, does it write into content you would otherwise own cleanly, and is there an export in a format something else can read? An add-on that owns your content and offers no export is not a purchase; it is a tenancy agreement.
5. Weight and blast radius. Does it load on every page or only where it is used? Does it hook into checkout, authentication, or anything else that fails expensively? How to check: the documentation's description of where it operates, plus a simple before-and-after page-weight measurement on a test install. Anything touching payments or logins should be held to a higher standard on all the other criteria, because its failures are the costly kind.
6. Licence and renewal model. The sticker price is year one. How to check: the pricing page's small print. Specifically: is the renewal at the same rate or a promotional first-year rate; is it per site or per account; and what happens when a licence lapses. The common commercial pattern is that a lapsed licence stops updates and support while the software keeps running — which sounds harmless and means an unpatched dependency sitting in your site indefinitely. Note whichever pattern the vendor states, because it varies.
7. Overlap. How many things in your existing stack already do part of this job? How to check: list your installed add-ons and what each is for. Two plugins doing halves of the same job cost twice the maintenance and create the conflicts that update days are made of.
Turning that into a decision
Criteria without weights are just a list. Set the weights from the use case before you score anything, and write down why:
- If the add-on touches payments, bookings or logins, weight maintenance cadence, support behaviour and blast radius heavily. Features are a distant second, because a missing feature is an inconvenience and a broken checkout is lost revenue.
- If it is cosmetic or editorial — a gallery, a slider, a layout helper — weight the data footprint and weight, because the likeliest future event is that you replace it during a redesign.
- If it will hold customer records, weight the exit cost above everything. The question is not how well it works; it is how you get your data out in three years.
Then score the shortlist on the stated criteria and pick the highest score for that use case, not in the abstract. The general version of this method — turning a vague purchase into explicit criteria and weights — is in our software buying process guide, and the business-software application of it is in how to choose business software.
The compounding cost nobody prices
Here is the part that makes this a maintenance question rather than a purchasing one.
Every add-on you install adds a permanent obligation: it must be updated, its update must be verified, its licence must be renewed, its conflicts must be diagnosed, and its vendor must be watched for the day they stop caring. Twenty add-ons is not twenty times the work of one — the update-conflict surface grows faster than the count, because any two of them can interact.
That is why "it's free" is such a misleading input. The purchase price is a rounding error next to the recurring obligation, and the obligation lands on whoever maintains the site — usually the owner, usually unbudgeted, usually at the worst moment.
Who carries the running cost
Once a stack passes a certain size, the honest options are to prune it or to pay someone to carry it.
Pruning first: uninstall anything you cannot name a current use for, consolidate overlaps, and prefer one well-maintained dependency over three narrow ones. That is free, and it is the highest-return hour available.
For what remains, a maintenance plan is the model that converts a variable obligation into a fixed cost. For a WordPress site, WPCare is a useful one to hold this article's criteria against, for two reasons that are relevant to total cost rather than to marketing. It states that it works from a vetted stack rather than deploying unvetted dependencies — which is criterion 1 and 5 applied by someone else, on your behalf, as a standing policy. And it publishes that client sites get access to its agency-licensed premium tooling, naming the specific products included; that is criterion 6 turned into a consolidated line, and it is the sort of claim you can price directly against what you currently renew yourself.
Do apply the same scepticism you would apply to any vendor: ask which tools are included by name, whether the licences travel with you if you leave, and who owns the configuration. A plan that reduces your renewal count but creates a new exit cost has moved the problem rather than solved it.
FAQ
Is a paid add-on more reliable than a free one? Not inherently. Payment funds maintenance, which correlates with reliability — but plenty of free tools are actively maintained by teams with a commercial reason to keep them healthy, and plenty of paid ones are abandoned with an active billing page. Judge the maintenance signals, not the price tag.
How many add-ons is too many? There is no number. The useful test is whether you can name what each one does and why it is still there. If you cannot, the count is already too high — and the ones you cannot name are the ones most likely to be unmaintained.
Should I remove an add-on I have stopped using, or just deactivate it? Remove it. Deactivated code still sits on the server, still needs updating to stay safe, and still shows up in every audit. Deactivation is a debugging step, not a decision.
What if the best option on features scores badly on maintenance? That is the trade-off worth naming out loud: you are buying capability now against a probable migration later. Sometimes that is correct — a genuinely unique capability with no alternative. Make it a conscious choice with a rough date attached, not an accident.
The bottom line
Compare add-ons on what they will cost you after the purchase: maintenance cadence, support behaviour, ownership stability, data footprint, blast radius, renewal model, and overlap with what you already run. Weight those criteria by the job the add-on does, prune anything you cannot justify, and be honest about who is carrying the recurring obligation. If that person is you and the stack has outgrown the time you have, pricing a maintenance plan — WPCare is one example for WordPress sites — is a legitimate line item, not an admission of defeat.
