Your Integrations Are a Liability, Not a Feature

"Integrates with over two hundred applications." It is one of the most reliable selling points in software, printed on every comparison sheet, and it lands because it sounds like pure generosity: look how much this connects to, look how much you can plug in, look how flexible it is. A longer integration list reads as a longer list of things the product can do, and more is better, so the platform with more integrations wins the box-ticking exercise.

That reading has the sign wrong on half of what it is counting. An integration is not only a capability. It is a dependency, a connection between two systems that has to keep working, that breaks when either side changes, and that someone has to maintain for as long as you run it. Every integration you add is a new place the system can fail and a new standing obligation on whoever keeps the lights on. Counted honestly, a long list of integrations is not only a list of things you can do. It is also a list of things that can break, and the second list grows every bit as fast as the first.

The reliability math is not on your side

This is not a matter of opinion. It is a basic result from reliability engineering, and it works against integration count directly.

When components are connected in series, so that the whole depends on each part working, the reliability of the system is the product of the reliabilities of its parts, and the failure rate of a series system is always higher than that of any individual component, with reliability dropping fast as the number of components grows. The intuition is simple: if the whole chain needs every link intact, then every link you add is one more thing that can break the chain, and the chance that all of them are working at once goes down with each addition, not up.

Integrations are exactly this kind of series dependency. A workflow that runs across your core system, an integration, and a connected application works only if all three are up, compatible, and in sync. Each integration in the path is another link whose failure takes the workflow down. So a platform with two hundred integrations is not two hundred times more capable in any way that matters; it is a system with up to two hundred additional links, each of which can fail, and the more of them a given process depends on, the lower its odds of working end to end on any given day. The feature list counts the links as assets. The reliability math counts them as risks, and the math is right.

Why each integration is a standing cost, not a one-time gain

The liability is not only about failure at a moment. It is about the continuous maintenance an integration demands for its entire life, which the purchase decision almost never accounts for.

• It breaks when either side changes -: An integration connects two systems built by two different vendors on two different release schedules, and when either one changes its data format, its interface, or its behavior, the integration can break. You do not control both ends, so you are exposed to changes neither you nor one vendor initiated, and keeping the connection working means reacting to other people's updates indefinitely.

• It has to be maintained, and the maintenance adds up -: Each integration carries an ongoing cost in monitoring, troubleshooting, and updating, and across many integrations that cost becomes substantial. Industry analyses of integration-heavy estates describe teams reaching a threshold where maintaining the connections they already have consumes more effort than building anything new, so the integrations meant to extend the system end up absorbing the capacity that would have improved it.

• The count explodes faster than you expect -: Connections do not grow one at a time with systems. Five systems that all talk to each other need ten connections; ten systems need forty-five. The number of integration points rises much faster than the number of systems, so a landscape that felt manageable becomes a web of dependencies surprisingly quickly, and every strand is one more thing to monitor and one more thing that can snap.

• Failures cascade -: In a tightly connected estate, a single change, a schema altered in one system, an API version retired, can break several downstream integrations at once, and problems propagate along the connections rather than staying contained. The more integrated the system, the further a single failure travels before it stops.

None of this appears on the comparison sheet, where each integration is a checkmark in the plus column. It appears later, in the maintenance burden, the cascade of breakages after someone else's update, and the slow realization that the connectivity you bought as a feature is functioning as a tax.

What this looks like in a property operation

The pattern is concrete in property management, where operations often run across a stack of separately-chosen tools.

A property company assembles its operation from a core platform, a separate accounting system, a payments provider, a screening service, and a maintenance-management tool, each connected by an integration, and each connection sold as a feature that made the stack more capable. Then the accounting vendor ships an update that changes a data format, and the sync to the core system quietly starts failing, and month-end numbers are wrong until someone traces the break. A payments provider changes an interface, and rent postings stall. Each integration worked the day it was demonstrated, and each became, over time, a dependency the operation now rests on and a place it can fail. The stack is more connected than it used to be, and by exactly the same measure it is more fragile, because connection and dependency are the same thing counted from two directions.

The honest part

Several qualifications keep this from becoming an argument against integration, which would be wrong and impractical.

Integrations are genuinely necessary and often valuable, and no real operation runs as an island. You will always need some connections, to a bank, to a payments processor, to a service the platform genuinely should not try to be, and a well-built, well-maintained integration to a system you truly need is a good and reasonable thing to have. The argument is not to avoid integrations. It is to stop counting them as unqualified assets and start counting each as the dependency it also is, so the decision to add one weighs the ongoing liability, not just the capability.

It is also true that not all integrations carry the same risk, and treating them as uniformly dangerous is as wrong as treating them as uniformly free. A stable, well-supported, standards-based integration to a major system that rarely changes is a modest liability; a fragile connection to a tool that updates constantly and breaks often is a heavy one. The number of integrations matters less than their quality and their necessity, and a few solid ones are far better than many brittle ones. Counting the list length, in either direction, is the crude version of the analysis; the real question is which connections you actually need and how well they are built.

And the most reliable way to reduce integration liability is not better integrations but fewer of them, which is where architecture matters more than any feature list. Capability that lives natively in one system needs no integration to reach the rest of that system, because there is nothing to connect, the reliability math that punishes a long chain of links rewards a design with fewer links to begin with. This is the same one-system-versus-two distinction examined in native isn't a feature, it's a decision you make once: the integration you never had to build is the one that can never break, and a platform that delivers a capability natively has removed a dependency rather than added a connector. Fewer seams is not a smaller feature list. It is a more reliable system.

Count the liability, not just the capability

The practical discipline is to evaluate integrations the way you would evaluate any standing dependency, weighing what each one costs to keep alive against what it delivers, rather than treating a long list as a pure win.

When a vendor presents an integration count as a strength, treat it as a neutral fact that needs examining rather than a point in their favor. Ask which integrations your operation would actually depend on, since those are the ones whose failure would hurt, and how robust each of those connections is: how it handles changes on either side, how often it breaks, who maintains it. Prefer capability delivered natively over the same capability reached through an integration, because native has no connection to break. And where an integration is genuinely needed, choose it deliberately, as a dependency you are accepting with its maintenance cost understood, not as a free feature you are collecting.

There is a single question that reframes the whole feature list. For every integration I am counting as a benefit, am I also counting it as something that has to keep working, and that will break when the thing on the other end changes? If the honest answer is that you have been reading the integration list as pure upside, then you have been counting only half of what is there, and the other half, the maintenance, the fragility, the cascade when one connection fails, is the half that determines how the system actually behaves over years. Integrations are sometimes necessary and occasionally excellent. They are never free, and a platform that needs fewer of them to do the same job is not the one with the shorter feature list. It is the one that will break less.

FAQs

Q1. Isn't a long list of integrations a good thing?
Only partly, because the list counts capability while ignoring liability. Each integration is also a dependency that must keep working, breaks when either connected system changes, and requires ongoing maintenance. A longer list is therefore also a longer list of things that can fail and must be maintained. Integrations can be valuable, but reading the count as pure upside ignores half of what each one actually is, which is a standing obligation and a potential point of failure.

Q2. Why do more integrations reduce reliability?
Because integrations are series dependencies: a workflow spanning several connected systems works only if all of them are up, compatible, and in sync. Reliability engineering shows that the failure rate of a series system is always higher than that of its individual parts, and overall reliability drops quickly as components are added. Every integration in a process is another link that can break the chain, so the more a workflow depends on, the lower its odds of working end to end.

Q3. What ongoing costs does an integration carry?
It must be monitored, troubleshot, and updated for its entire life, and because it connects two independently-maintained systems, it breaks when either side changes its format, interface, or behavior. Across many integrations this maintenance becomes substantial, and integration-heavy operations often reach a point where maintaining existing connections consumes more effort than building anything new. The cost is continuous and largely invisible at purchase, which is why it is so often underestimated.

Q4. Why does the number of connections grow so fast?
Because connections scale with the relationships between systems, not the count of systems. Five systems that all interconnect need ten connections; ten systems need forty-five. The integration points rise much faster than the systems themselves, so a stack that felt manageable becomes a dense web of dependencies surprisingly quickly, and each strand is one more thing to monitor and one more thing that can fail. Integration sprawl tends to creep up well ahead of expectations.

Q5. What does integration fragility look like in property management?
A stack assembled from a core platform, accounting system, payments provider, screening service, and maintenance tool, each joined by an integration sold as a feature. Then an accounting update changes a data format and the sync fails quietly, leaving month-end numbers wrong until someone finds the break; or a payments interface changes and rent postings stall. Each integration worked at demonstration and later became a dependency the operation rests on and a place it can fail.

Q6. Are you saying we should avoid integrations?
No. Integrations are necessary, and no real operation runs in isolation, you will always need connections to banks, payment processors, and services the platform should not try to replicate. A well-built, well-maintained integration to a system you genuinely need is a reasonable thing to have. The point is to count each integration as the dependency it also is, weighing its ongoing liability alongside its capability, rather than treating a long list as unqualified benefit.

Q7. Do all integrations carry the same risk?
No, and that distinction matters. A stable, standards-based integration to a major system that rarely changes is a modest liability; a fragile connection to a tool that updates constantly and breaks often is a heavy one. The number of integrations matters less than their quality and necessity, and a few solid connections beat many brittle ones. The useful analysis is which connections you truly need and how well each is built, not the length of the list in either direction.

Q8. How do we reduce integration liability?
The most reliable way is to need fewer integrations, which is an architecture question rather than a feature one. Capability that lives natively in one system requires no integration to reach the rest of that system, because there is nothing to connect and therefore nothing to break. The reliability math that penalizes a long chain of links rewards a design with fewer links from the start, so a platform that delivers capabilities natively has removed dependencies rather than added connectors.