1. Default to core and theme first
Block patterns, navigation menus, template parts, and the block editor cover a surprising share of “we need a plugin for that.” I prove the need in a child theme or style variation before adding a dependency. Presentation belongs in the theme; persistent business logic belongs in a plugin—splitting those cuts duplicate sliders, duplicate SEO suites, and duplicate page builders.
2. One job per concern, not one plugin per whim
When three plugins each add analytics pixels, social meta, and “performance” tweaks, consolidate to one maintained solution or a tiny custom integration you control. I keep a written rule: no second plugin for the same concern unless the first is demonstrably abandoned or unsafe.
3. Use mu-plugins and small custom plugins for glue
Site-specific tweaks—redirect rules, short admin helpers, webhook endpoints—often fit in a single must-use or client plugin instead of five “utility” plugins from the directory. That reduces update noise and keeps behavior visible in Git.
4. Audit like an SRE, not a shopper
Quarterly (or before any major campaign), I export the active list and ask for each row: who owns it, what breaks if it disappears, and whether another component already does 80% of the job. Inactive plugins get removed from disk; trial plugins do not linger “just in case.”
5. Measure the cost of activation
Before keeping a plugin, I check front-end scripts, autoloaded options, cron events, and database footprint. Heavy plugins are not evil—but they need a named owner and monitoring, same as custom code.
6. When extra plugins are the right call
Security scanning, reliable backups, accessibility linting, and mature commerce stacks are often cheaper as maintained products than DIY. The goal is not minimalism theater—it is no redundant moving parts.
Extend WordPress with clarity: fewer, sharper boundaries, owned glue code where it belongs, and regular pruning. Your future self—and every visitor’s Time to Interactive—will notice.