The plugin trap: why "just add an integration" quietly becomes a liability
Adding one more plugin, one more automation, one more third-party integration always looks like the cheap option in the moment — cheaper than custom development, faster than a proper architecture review. Individually, that's often true. The trap is that nobody evaluates the cost of the tenth integration against the system as a whole; each one only gets compared to building it from scratch.
How the trap gets set
It starts reasonably. A form plugin to handle enquiries. A booking plugin for appointments. An email automation tool to follow up on both. Each decision is made in isolation, by whoever is solving that week's problem, and each one is individually a sound, well-justified choice.
What doesn't get evaluated at any single decision point is the growing web of dependencies between them — the booking plugin now expects a specific field format from the form plugin, the automation tool is watching for a webhook that one specific version of one specific plugin fires, and nobody has mapped the whole chain in one place.
Where the cost actually lands
The bill comes due at update time. A routine security update to the form plugin changes a field name, silently breaking the automation that depended on it, and nobody notices until a customer complains that their booking confirmation never arrived. Diagnosing that failure means understanding four different tools built by four different vendors, none of whom know the others exist.
It also compounds over time in a less visible way: performance. Every plugin adds page weight, database queries and points of failure. A site that started fast accumulates friction one reasonable-sounding addition at a time, and by the time it's noticeably slow, untangling which of fifteen active plugins is responsible is its own investigation.
The alternative isn't 'build everything custom'
The fix isn't refusing integrations — most organisations genuinely need several. It's evaluating each one against the system as a whole, not in isolation: what does this depend on, what will depend on it, and who is responsible for noticing when an update breaks that chain.
In practice that means keeping a simple, current map of what's actually connected to what — which doesn't need to be sophisticated, just current — and treating 'does this get properly maintained by someone with visibility into the whole system' as a real selection criterion, not an afterthought applied only once something has already broken.
Takeaways
- No single integration decision looks expensive — the cost is in the interactions between integrations nobody evaluated together.
- Routine updates to one tool are the most common trigger for a silent failure in another, connected tool.
- A simple, current map of what's actually connected to what is worth more than sophisticated documentation nobody keeps updated.
- The right question for a new integration isn't just 'does this solve today's problem' but 'who is responsible for noticing when it breaks something else.'