What are we actually paying for?

The parts nobody demonstrates. Credential handling, retries that do not duplicate work, respecting each service's limits, mapping fields that disagree, and absorbing the change when a vendor alters its interface. All of it is invisible while things work, and all of it becomes somebody's problem the moment you decide to build the links yourself.

When is building it ourselves the right answer?

When there are very few links, they are unlikely to multiply, and somebody has clearly agreed to own them. Two systems joined once by a team that maintains software anyway is a reasonable piece of work. The reason to buy is that estates rarely stop at two, and each addition arrives with the same permanent obligation.

What usually goes wrong at scale?

The bill, well before the capability. Per-task pricing punishes volume, credit-based pricing compounds more slowly and still compounds, and self-hosting swaps the invoice for operational work that needs an owner. Teams almost always meet the economic ceiling first, so the arithmetic at your expected volume is the decision.

Glossary

Integration platform

An integration platform exists to connect other products, holding the credentials, the retry logic and the upkeep so that joining any two systems stops being a separate small project.

In plain terms

A product whose entire job is joining your other products together. On its own it does nothing you would describe to a colleague. What it removes is a pile of small, tedious, permanent work: holding the logins, retrying when something is briefly down, and quietly keeping up when one of those products changes how it works.

Why it matters

Because the alternative is not zero work, it is the same work done many times by people who did not want it. Every pair of systems joined by hand needs somebody to hold its credentials, handle its failures and repair it when a vendor changes something, and that obligation never appears in the estimate for joining them. Buying the middle is buying somebody else's maintenance.

How it works

The value is concentrated in the unglamorous parts, which is why demonstrations undersell it. Holding credentials safely, retrying a failed call without duplicating the work, respecting each service's limits and mapping mismatched fields are all invisible when things go well and are most of what you are paying for. A demonstration shows the boxes; the bill is for the middle.

Breadth is the durable advantage, because the long tail is where hand-built work concentrates. Connecting two popular products is straightforward however you do it, and the value appears at the niche system nothing else speaks to, which is precisely the one a team would otherwise wire up themselves. That reach is expensive to build and expensive to maintain.

Upkeep is the part that is genuinely transferred. Products change their interfaces on their own schedule, and when they do a hand-built connection breaks and becomes somebody's urgent afternoon, while a platform absorbs the change and most customers never learn it happened. That is the difference in ownership, and it compounds across a large estate.

Pricing shape decides the ceiling, and it differs sharply between platforms. Per-task billing is the quickest route to something working and climbs steeply with volume, credit-based billing undercuts it at scale and still compounds, and running the platform yourself converts the bill into operational effort somebody must own. Teams meet that ceiling well before they meet a limit on what can be connected.

What the estimate covers, and what it misses

The reason teams underestimate this so consistently is that the left-hand column is genuinely easy and genuinely finishes. Somebody joins two systems in an afternoon, it works, and the conclusion that this was simple is entirely reasonable on the evidence available that day. The right-hand column does not arrive until later and does not arrive all at once: a duplicated record three weeks in because a retry was naive, a silent stop when a limit was hit, an outage the morning after a vendor changed a field name that nobody was watching for. Each is small and each lands on whoever is nearest, which by then is rarely the person who built it. Multiply by a dozen links and the estate has acquired a maintenance job that nobody was hired for and nobody scheduled. That job is the product being sold here, which is why it demonstrates so badly and matters so much.

Seen in the wild

The broadest platform of its kind, whose durable advantage is the long tail of niche applications nothing else speaks to.
Zapier
A platform connecting thousands of applications on a canvas where branching, error handling and transformation are first-class rather than bolted on.
Make
A self-hostable platform where residency, control and cost all follow from running it on infrastructure you operate yourself.
n8n

Common misconceptions

People assume

We could just build the connections ourselves.

In fact

You can build any one of them, and the cost is not the building. Each hand-built link acquires an owner for its credentials, its failures and its repair when the far end changes, and that obligation runs for as long as the link does. Platforms are bought to move that obligation, not to save the first afternoon.

People assume

They differ mainly on how many applications they support.

In fact

Counts converge and pricing shape does not. Almost every platform reaches the systems most teams use, so the ceiling that actually arrives is billing at volume, which diverges enormously between per-task, per-credit and self-hosted arrangements. Model the arithmetic at the volume you expect rather than counting logos.

Telling them apart

Integration platform vs Connector

Integration platform

The product that holds and maintains the links.

Connector

One prebuilt link to one system.

A platform is a shop full of the second, plus the credentials, retries and upkeep that make having many of them survivable.

Questions

What are we actually paying for?: The parts nobody demonstrates. Credential handling, retries that do not duplicate work, respecting each service's limits, mapping fields that disagree, and absorbing the change when a vendor alters its interface. All of it is invisible while things work, and all of it becomes somebody's problem the moment you decide to build the links yourself.
When is building it ourselves the right answer?: When there are very few links, they are unlikely to multiply, and somebody has clearly agreed to own them. Two systems joined once by a team that maintains software anyway is a reasonable piece of work. The reason to buy is that estates rarely stop at two, and each addition arrives with the same permanent obligation.
What usually goes wrong at scale?: The bill, well before the capability. Per-task pricing punishes volume, credit-based pricing compounds more slowly and still compounds, and self-hosting swaps the invoice for operational work that needs an owner. Teams almost always meet the economic ceiling first, so the arithmetic at your expected volume is the decision.

Key takeaways

The value is credentials, retries, limits and upkeep, none of which demonstrate well.
Breadth matters at the niche system, not at the popular one.
Buying it moves an obligation rather than saving an afternoon.
Pricing shape is the ceiling teams actually meet.