The Connections Bill: Why Integration Costs Outlive the Application Budget
Photo: TheAHL, CC BY 2.0, via Wikimedia Commons
Ask a finance team what a custom software project cost and they will usually quote the number on the approved capital request. Ask the same question three years later, after the ERP has been upgraded twice, the payment processor has deprecated a version of its API, and a new warehouse system has arrived through an acquisition, and the answer will be materially higher. The gap between those two figures is rarely fraud and rarely incompetence. It is the integration tax, and it is almost never in the original estimate.
The line item that never makes it into the estimate
Integration appears in early planning as a percentage. A vendor will estimate the application at a given figure and add something for connecting it to the surrounding systems. That percentage is treated as a contingency rather than as a forecast, and it is usually derived from the number of systems involved rather than from the behavior of those systems over time.
The distinction matters. An application is a bounded object. It has a specification, an acceptance test, and a moment when it is finished. A connection is not bounded in the same way. It depends on a third party that has its own release calendar, its own deprecation policy, its own outage history, and no contractual obligation to the buyer whatsoever. The application gets delivered. The connection gets re-delivered, indefinitely, at the buyer's expense.
Four components of the tax
The first is build cost: the initial work of mapping fields, handling authentication, reconciling data models that were never designed to agree, and building the error handling that real integrations require. This is the portion most likely to be estimated, and even it is frequently underestimated by a wide margin.
The second is middleware and licensing. Enterprise integration platforms carry subscription costs that scale with connectors, volume, and environment count. A company that adds four integrations in year one and eleven by year three often finds that the middleware line has grown faster than the application's own hosting costs.
The third is change absorption. Every third-party upgrade is a potential break. Some upgrades are announced with generous notice. Others arrive as a mandatory security patch that alters response formats on a Tuesday afternoon.
The fourth, and least visible, is the coordination overhead. Integration work requires people who understand two systems at once, and those people are scarce. When the vendor who built the connector has moved on, the buyer pays a premium for rediscovery before any new work begins.
Why the bill compounds instead of repeating
A recurring cost is manageable. A compounding one is not. Integration costs compound because each connection increases the number of pairwise relationships that must remain stable. Five connected systems generate far more than five interactions once data flows in both directions and business rules are applied at each boundary.
They compound again because the systems on either end are aging at different rates. The ERP is upgraded on a multi-year cycle, the CRM twice a year, the payment processor whenever it chooses. Nothing in the arrangement synchronizes these clocks, and each upgrade resets the risk profile of every connection touching it.
And they compound a third time through knowledge decay. The engineer who understood why a particular field is transformed in a particular way leaves. What remains is a working integration that nobody can safely modify, which is a polite way of describing a future emergency.
Surface area as the real evaluation metric
Feature comparisons miss all of this. A better instrument is dependency surface area: how many external systems the application must touch, how many of those are controlled by third parties, how frequently each changes, and who is responsible for adapting when they do.
A modest application with eleven integrations into systems the buyer does not control carries more long-term risk than a larger application with two. Buyers who adopt this lens tend to ask different questions during selection, and vendors notice. They start proposing consolidation, cached data patterns, and asynchronous boundary designs that reduce coupling — options that exist in every project but rarely surface unless someone asks.
Negotiating ownership before the signature
Integration ownership is the term that determines who pays for the tax. It should be settled in the contract, not in a change order.
Specify who owns the connector code and where it lives. Establish who is responsible for monitoring failures and what the response time is. Define what happens when a third-party API changes: is adaptation included in a support agreement, or billed separately at prevailing rates? Require documentation sufficient for a competent third party to maintain each connection, including the business rules encoded in every transformation.
Finally, obtain a written inventory of every external dependency at delivery, with version numbers, contact points, and renewal dates. That inventory is the buyer's map of the tax. Without it, the organization is paying a bill it cannot itemize, for connections it cannot enumerate, to systems it does not control. Few positions in business are less defensible than that one.
