A New Zealand tourism site went down because of a slider.
The hosting environment moved to PHP 7.4. The homepage slider plugin was incompatible. The WordPress backend stopped loading, and the fix was to disable the plugin. That took about thirty seconds. The risk had been sitting there for years.
The broken feature was decorative. A rotating image at the top of the homepage could have been replaced with a static image and a few lines of CSS. Instead it was a separate codebase, with its own author, update cycle, PHP compatibility, admin settings, assets, and failure mode.
Forms, caching, SEO, page builders, and ecommerce can all justify a proper plugin when the site needs the capability. The expensive part is the long tail: small plugins that do one minor behaviour and stay active for years.
In a 2026 plugin review, a restaurant site was built entirely with Divi, but still had Elementor sitting in the installation. The Elementor event table was empty. No pages depended on it. On the same site, all 352 orders had gone through WooPayments while a second Stripe plugin was enabled with no orders using it.
Another ecommerce site had two anti-spam plugins processing forms. Both were trying to protect the same checkout path, which means two sets of validation, two external services to understand, and one more thing to inspect when checkout slows down or fails.
A media site had two redirect managers. One held 5,615 redirects. The other held 1,843. Two redirect managers with live rules in both places is an ownership problem: which plugin is now the source of truth for a visitor, a search crawler, or a future migration?
This is why I do not start a plugin review by asking whether the plugin is large or small. I ask what decision it is making for the site.
Does it own customer-facing behaviour, admin convenience, stored data, checkout logic, analytics, redirects, forms, product feeds, security, or backups? Is there evidence the decision is still active: shortcodes in pages, custom tables, options, post types, orders, form entries, hooks in the theme, or a live integration?
A form plugin with 15 live forms and 410 submissions is probably part of the business process. A payment plugin with zero orders through it is not. A redirect plugin holding thousands of redirects needs migration planning, not a casual deactivate button. A plugin that only opens external links in a new tab is a small site behaviour in the wrong place.
For those small site behaviours, site-owned code takes the behaviour out from behind another plugin brand, another settings screen, another license renewal, and another update notice.
That changes handover. When a new developer opens the project, they can see the custom behaviours in one place: external links, login redirects, comment rules, tracking snippets, editor tweaks, small display changes. They can see when the file changed, who changed it, and why. They are not reconstructing the site’s behaviour by clicking through plugin settings and guessing which checkbox matters.
It also changes update risk. A small piece of site-owned code still has to be maintained, but it does not have an external author changing the interface, adding admin notices, changing pricing, or dropping PHP compatibility for a feature that only needed a few lines in the first place.
