Why some integrations cost more than the systems they connect.

The estimate covers the connection, the invoice covers the gaps

Integration estimates nearly always describe the same work: read data here, transform it, write it there, with authentication and a schedule. That part is real, well tooled, and it usually lands close to the quoted effort.

What overruns is everything sitting between the two systems: the cases where data exists on both sides but means different things, the cases where it arrives out of order, and the cases where nobody is authorized to decide. These gaps do not surface during design. They surface in production, one at a time, and each one needs a business decision before it can be coded.

Three gaps that generate most of the spend

Same word, different definitions

In the sales tool, an "active customer" is an account that ordered in the last twelve months. In the accounting system, it is an account with no outstanding balance. In the commerce platform, it is an account whose access has not been suspended. All three definitions are legitimate in context, and none converts into the others without an arbitration rule nobody has written.

This kind of gap is settled by a business decision, not a transformation script. Development stalls until the call is made, and the call stalls until someone is named to make it.

Events do not arrive in order

A remote system returns a temporary error, the call is retried, and the same order is created twice. An address update arrives before the account it belongs to. A message is delivered twice because the acknowledgement was lost on the way back.

These are not rare anomalies; they are the normal operating conditions of any exchange between independent systems. Serious interfaces say so explicitly — Stripe's API, for instance, documents idempotent requests, which let a call be replayed without creating the same operation twice. Deciding whether exchanges must be idempotent, and how they get replayed, is a design choice that comes before choosing a tool.

Nobody owns the flow

An integration connects two teams as much as two systems. The law Melvin Conway published in 1968 remains uncomfortably accurate: organizations produce systems that mirror their own communication structures. An integration between two departments that rarely talk will be a poorly defined integration.

With no designated owner, every incident triggers the same sequence: each side confirms its own half works, concludes the problem is elsewhere, and the flow stays down until the conversation happens. The cost is not in the fix. It is in the decision delay, repeated at every incident for years.

An integration with no owner is not free. Its cost is simply spread across every team that has to live with it.

The shortcut that costs the most

Faced with all this, the fastest path is often to read straight from the other system's database. No interface to negotiate, no rate limits, a working result in days.

Martin Fowler documented the price of that shortcut long ago: a database shared by several applications becomes an implicit contract between them. Nobody can change its structure without risking a consumer they have never met. The integration ships quickly, and both systems become slower to change for the rest of their lives.

The documented alternative is to insert a translation layer — an anti-corruption layer, in domain-driven design vocabulary — whose job is to absorb model differences so each system keeps its own. It costs more to build, and it avoids exactly the freeze described above.

What to settle before signing anything

Most of these costs are determined before the first line of code, when you define what gets exchanged and who answers for it. Five points are enough to expose the bulk of the real work.

None of these is a tooling question. They arise identically with a commercial integration platform, a message queue or a handful of scheduled calls — and they shape the final cost far more than the technology does.

Integrations get expensive when they carry unresolved disagreements between two parts of an organization. A well-prepared integration does not remove those disagreements. It simply forces them to be settled before they turn into incidents.