The Fragility of Point-to-Point Middleware

Every revenue stack acquires middleware the same way. Someone needs prospecting data in the CRM by Friday. A connector tool does it in an afternoon — no developer, no ticket, no waiting. The trigger fires, the field maps, the test record lands. It is a genuinely great product experience, and nothing in this essay disputes it.

The argument is about what that afternoon quietly purchased: a third company standing between two systems you own, holding the connection on its accounts, its quotas, and its uptime — invisible on the org chart and absent from every architecture conversation until the day a quarter’s pipeline report fails to reconcile.

It works — that’s the trap

Point-to-point middleware is at its best on day one and at its worst at scale, and the slope between those points is smooth enough that no single day feels like the day it broke. A connector that moves forty records a month is a convenience. The same connector moving four thousand is core infrastructure — except nothing about it changed when it crossed that line. Nobody re-evaluated it, because nothing failed. It was promoted from experiment to load-bearing by silence.

That promotion-by-silence is the category’s defining property. Real infrastructure earns its position through review: someone sizes it, someone owns it, someone decides it is fit for the load. Middleware inherits the position without the review, because the review moment never arrives — there is no go-live for something that has already been running for a year.

Failure is silent by design

When a direct integration fails, the failure belongs to one of the two systems involved, and those systems have owners. When a connector fails — an expired auth token, a paused automation, a changed field name upstream — the failure happens inside a third product that nobody is staring at. The error message renders faithfully, in a dashboard that isn’t anyone’s job to open.

So the failure surfaces downstream, translated beyond recognition: a rep who never got the hand-off, a campaign that stopped writing attribution, a pipeline report that disagrees with the sending tool. By the time someone traces it back through the stack to a connector that stopped running in March, the question isn’t how to restart it — it’s how much of the intervening data can be reconstructed, and how much is simply gone.

This isn’t a bug in any particular tool. It is the structural consequence of putting the join — the part most likely to fail — inside the product with the least operational attention on it.

The meter runs on your success

The dominant pricing model in this category is per task: every record moved is a billable event. Read that as an incentive structure and the strangeness surfaces — your integration bill is indexed to your growth. The connector between prospecting and CRM costs the most in exactly the months your outbound works best.

A direct integration inverts the curve: the cost is the build, paid once, and volume is free. Middleware is cheaper on day one and crosses over at some volume you won’t notice passing — because the price rises a plan tier at a time, each one individually too small to trigger a re-architecture, collectively a permanent tax on the motion the stack exists to serve. And it renews forever: stop paying, and data stops flowing between two systems you already pay for.

Nobody owns the middle

Ask who owns the CRM and you get a name. Ask who owns the sending tool — a name. Ask who owns the connector between them and you get a story: a contractor set it up, or a marketer who has since left, on an account that may be personal, with credentials nobody has rotated because nobody is sure what rotating them would break.

The automation outlives its author — reliably, because the whole pitch of the category is that building one takes an afternoon and no engineering review. Work that cheap to create is work nobody documents. Multiply by a few years and the middle of the stack is an archaeology site: automations whose purpose is inferred from their names, triggers nobody dares disable, and a vendor relationship — billing, quotas, uptime — that appears on a credit card statement and nowhere else.

What volume does to all of this

Every property above is survivable at low volume, which is why the category thrives — most workflows start at low volume. Scale is what converts each one from a quirk to an incident. Any given step fails rarely; run enough of them and rare becomes routine, each failure silent by default.

Batches make it worse: a run that dies halfway leaves half the records moved with no ledger of which half, and the obvious remedy — run it again — now writes duplicates into the CRM, which is how a sync problem becomes a data-quality problem. Task quotas add a calendar irony: the quota fills at month-end, in the highest-volume weeks, which are the weeks the pipeline mattered most. None of these are edge cases. They are what the architecture does under load.

The alternative is boring on purpose

A direct webhook is one hop: the source system calls your CRM, on your accounts, with no metered third party in the path. What makes it infrastructure rather than plumbing is that failure behavior is designed instead of defaulted — a failed delivery retries; anything that still can’t complete is logged where an owner will see it and raised to that owner by name. The failure path gets the same design attention as the success path, which is precisely what the connector model omits.

It costs more than an afternoon, and it should — it is the part of the stack that everything else’s honesty depends on. The wrong question about a connector is whether it works; it works. The right question is who finds out when it stops — and if the honest answer is “whoever notices the report looks wrong,” the connection was never really built. It was deferred.