Integration Platform or Point-to-Point Integrations?

At the start, it’s enough to connect two systems directly. Then a third, a fourth, and suddenly there are more connections than anyone has oversight of. The question of integration platform or point-to-point isn’t about which is right in theory, but about when one approach stops holding up and the other starts paying off. The answer lies in how the number of connections grows.

Point-to-point: simple until it isn’t

Point-to-point means every system connects straight to the system it needs to talk to. CRM to accounting system, accounting system to warehouse, warehouse to webshop. Each connection is simple on its own, and when the systems are few, it’s both fastest and cheapest to just draw a line between them.

The charm is that you don’t need any extra infrastructure. You solve exactly the need that exists, when it exists. As long as the number of systems and flows is small, point-to-point is often entirely right – introducing a platform would be like building a highway to drive to your neighbor’s house.

The spaghetti problem

The problem is how it grows. The number of possible connections between systems doesn’t grow linearly but roughly quadratically: double the number of systems and the number of conceivable connections roughly quadruples. Every new system can need to talk to several of the existing ones, and the web quickly gets dense.

The result is often called spaghetti – a tangle of direct connections that no one has full oversight of. The consequences are concrete. A change in one system risks silently breaking several connections at once. The same logic – how a customer number should be translated, for example – sits built into several places and has to be changed everywhere at the same time. And when something goes wrong, it’s hard to even see where in the web the fault sits.

The integration platform and its overhead

An integration platform, often called iPaaS, solves this by putting a hub in the middle. Instead of connecting systems to each other, every system connects to the platform. Then the number of connections grows linearly with the number of systems instead of quadratically, and the web stays manageable.

The platform also brings other benefits: shared logic built once and reused, a consolidated view of all flows, and a single place to troubleshoot. When something goes wrong, you see it in one place instead of hunting through a tangle.

But it costs. A platform means license fees and – at least as important – a need for expertise to build and maintain within it. That’s a real overhead that doesn’t exist when you just draw a quick line between two systems. Introduce the platform too early and you’re paying for structure you don’t need yet.

Where’s the breakeven point?

The trade-off stands between low starting cost and low ongoing complexity. Point-to-point is cheap to start with but becomes expensive to live with as it grows. The platform is more expensive to introduce but cheaper to live with once complexity is high.

A useful rule of thumb is that the breakeven point often sits around five systems or ten flows. Below that level, the platform’s overhead is rarely justified. As you approach or pass it, the spaghetti web’s cost – in risk, duplicate work, and hard-to-debug errors – starts to exceed what the platform costs. The rule of thumb is just that – a rule of thumb; how critical the flows are and how often the system landscape changes affect where the line actually falls.

A reasonable way to think about it is to start with point-to-point when the needs are few and introduce a platform once the complexity justifies it. What matters is keeping track of the number of flows in time, so the switch happens before the web becomes unmanageable rather than after.

How to think about the choice

Count the systems and the flows, and ask how often they change. Few, stable systems argue for point-to-point. Many systems, many flows, and a landscape that keeps growing argue for a platform. The most expensive path is letting the spaghetti grow until it becomes a risk, because then you pay both for the mess and for untangling it.

At Weapp we build both individual integrations and platform-based architectures, and help you determine which step fits your particular situation. Check out our services or get in touch, and we’ll look at your system landscape together.