The N×N Problem: Why Every Integration Platform Collapses Under Its Own Connector Count

By Aaron Gammon · Founder, Inferrex · June 2026

This is the short, sharp companion to my pillar piece on comprehension over connection. That one makes the broad argument; this one does nothing but the maths, because the maths is the part that, once you've seen it, you can't unsee. It's the reason I'm confident the incumbents aren't behind through bad execution — they're behind through bad arithmetic, and execution can't fix an exponent.

Live platform figures are at inferrex.com/claims.

Open any integration platform's pitch and you'll find the connector count, displayed with pride: thousands of pre-built connectors. It's meant to read as strength — look how much we've already done for you — and on the day you buy, for the systems on the list, it genuinely is.

But a connector count is a strange thing to boast about when you look at it clearly. It's not a measure of value delivered; it's a measure of maintenance liability accumulated. Each connector is a hand-built snapshot of one provider, frozen at the moment it was made, that someone now has to keep alive as that provider changes. The catalogue isn't a vault of assets appreciating quietly. It's a fleet of perishable snapshots, each one waiting for its provider to move so it can break.

And here's the number that's never next to it: how many connections the catalogue can't make. That's the one that matters, and it's governed by an exponent.

The thing customers actually want isn't connectors. It's connections between their systems — this CRM talking to that warehouse, this billing system talking to that ledger. So count those.

With N systems, the number of possible pairwise connections is N×(N−1)/2 — on the order of N². Ten systems is forty-five possible connections. A hundred systems is nearly five thousand. The demand for connections grows as the square of the number of systems.

Now count the supply. A connector-catalogue platform builds and maintains connectors one at a time, by hand. Adding one more provider is one more connector to build and, forever after, one more to keep from breaking. The building effort grows in a straight line — linearly — with the number of providers.

So set the two curves side by side: demand climbing as N², supply trudging up as N. They start close, when N is small, which is exactly why a young platform looks like it's keeping up. Then N grows, the square pulls away from the line, and the gap between what customers want and what the catalogue can provide opens into a chasm that widens with every system added. You don't grow out of this. You grow into it.

That widening gap isn't an abstraction. It has a name in every organisation that's lived it: the integration backlog.

It's the "we don't support that provider yet." It's the custom-connector project that takes a quarter and a consultant. It's the long tail of niche, internal, and bespoke systems that no catalogue will ever build a connector for because the economics don't justify it. It's the breakage, too — because every connector already in the catalogue is a snapshot decaying toward the moment its provider changes and it snaps. The bigger the catalogue, the more snapshots there are quietly going stale, so the maintenance burden also grows with N while the new-connector demand grows with N². The platform is fighting a war on two fronts, both of which it's structurally losing.

The instinct, faced with a backlog, is to throw engineers at it — build connectors faster, hire a bigger team. It doesn't work, and the maths says exactly why.

More engineers raises the slope of the linear line. It does not change the fact that it's a line, fighting a square. You can build connectors twice as fast and the N² demand still outruns you; you've just outrun yourself slightly less slowly. There is no headcount that converts a linear process into a quadratic one. This is the trap the whole catalogue model is built inside: linear effort against quadratic demand, with hiring as the only lever, and hiring can't bend a line into a parabola. It's not an execution problem any amount of execution solves. It's the wrong exponent.

If the problem is that you're spending N² effort (or trying to, and failing) to satisfy N² demand by hand, the escape is to stop spending effort per connection and start spending it per system.

Comprehend each provider once — understand what its fields actually mean, in a shared canonical language — and it can reach every other comprehended system through that shared understanding. That's N acts of comprehension, not N² hand-built wires. The quadratic web of connections still exists and customers still get all of it; it just falls out as a consequence of N understandings rather than being assembled one wire at a time. You've moved the human effort from the exponential side of the equation to the linear side, and let comprehension supply the exponent for free.

That's the whole difference between a connector catalogue and a comprehension layer, reduced to arithmetic. One spends linear effort and falls permanently behind quadratic demand. The other spends linear effort to understand and gets the quadratic result as output. Over any real time horizon, those two curves are not in the same universe.

Whenever I see a connector count on a slide now, I see the exponent it's losing to. It's an honest number about the wrong quantity — effort spent, not connections possible — and it describes a model that looks strongest right before the square pulls away from the line.

The connector catalogue was a reasonable answer when N was small and APIs barely changed. N isn't small anymore, and APIs change constantly. The arithmetic that was forgiving in 2010 is merciless now. That's not a prediction. It's a parabola.