The problem was never plugging systems together
Ask anyone who has run an integration project, and they will describe the same frustration. It looks technical on the surface. Underneath, it rarely is.
“It was never the technology,” says Caspar, CEO of Alumio. “It was always the people in the organization. The IT manager who did not want to open the gates, or who had no real picture of how the whole thing fit together.”
The plumbing itself was usually mundane. Legacy systems were often sold as difficult to connect, but the reality was tamer. “Older software was sold as if connecting to it was incredibly hard,” Caspar says. “It almost always came down to the same thing. A file on a server, or a SOAP connection. And I would think, someone has made this far more complicated than it needed to be.”
If the technical work was manageable, the difficulty lived somewhere else. It lived in the organization, and in what happened after the integration went live.
What integration dependency actually looks like
When a business builds a custom integration, it does not just get a working integration. It inherits a set of dependencies it rarely accounts for at the time.
The first is dependency on the builder. The logic sits in one developer's head, or in code only they understand. When they leave, the knowledge leaves with them. This is often called key man risk: the danger that critical knowledge sits with a single person. Caspar has seen it more than once at mid-sized manufacturers. “They had everything built by one person, and that person left.” The systems kept running, but nobody inside the business understood them anymore.
The second is dependency between the systems themselves. Point-to-point connections tangle over time until one system cannot be replaced without breaking the others. Swapping an ERP stops being a project and becomes a risk nobody wants to take.
The third is dependency on the past. Because change feels dangerous, businesses keep running architecture they have already outgrown. “Businesses were not asking how to lay a foundation they could build on year after year,” Caspar says. “They would just rebuild it, and then rebuild it again a few years later.”
The bill arrives later, and it is not just money
The cost of integration dependency is easy to ignore because it does not show up as a line item. It surfaces slowly, in ways that are difficult to trace back to their source.
Caspar describes warehouse management connections that fail every few weeks and stay down for an hour or more at a time. Entire teams cannot work until they come back. What stands out is not the outage. It is that the business has come to treat it as normal. The hosting sits on a vague cloud invoice. The downtime sits in lost hours. Neither is labeled “dependency,” but both are real.
This is why the conversation has moved beyond IT. Investors and acquirers ask a different set of questions. Who can maintain this if the current team leaves? What is actually documented? What would it cost a buyer to take this over? Integration architecture has become part of due diligence, and undocumented custom work is one of the things that gets flagged. The practical consequence is that professionalizing the integration layer is no longer only an IT improvement. It is part of making a business transferable, and it pulls the owner and the CFO into a discussion that used to belong to IT alone. The same questions come up from the other side of the table during post-merger integration.
But the deepest cost is time. “There is really only one enemy for any business, and that is time,” Caspar says. “If money is not the constraint, it actually gets more dangerous, because people accept that things take unnecessarily long.” A business that cannot move at the speed of its market has a serious problem, and dependency is what slows it down.
Removing the dependencies custom integration creates
The answer is not to build better custom integrations. It is to avoid the dependencies that custom integrations create in the first place. That means changing where the integration logic lives, not how well it is written.
This is where an integration platform-as-a-service (iPaaS) changes the picture. The Alumio iPaaS is a cloud-native, config-first platform that connects business systems through a central layer, rather than through one-off custom links between each pair of systems. Each connection is set up through structured settings rather than written from scratch. That works with a pre-built connector where one exists, and with the system's own API where it does not. Alumio also provides a Code Transformer for developers who would rather solve an edge case in code. The point is not that the platform plugs things together more elegantly. The point is what it removes.
Put that central integration layer in place, and the logic of each connection lives in one visible, governed place rather than in a single developer's head. When an order is placed in the webshop, it routes to the ERP, updates inventory, and triggers fulfillment. The business can see and change that flow without depending on whoever originally wrote it. One system can be replaced without the others collapsing. The knowledge stays in the organization.
There is a trade-off worth stating plainly. Adopting a platform means standardizing, and standardizing means giving up some of the bespoke freedom custom builds offer. For businesses convinced their processes are entirely unique, that can feel like a constraint. In practice it is the opposite. It is what lets them change one system without renegotiating their entire architecture.
Why dependency is now a strategic question
None of this is static. The same pattern that started with pulling logic out of code is still unfolding. Caspar has watched the ground shift under this problem since founding Alumio, and his read is that it is still moving in the same direction.
“We started Alumio to take the technology out of the code,” Caspar says. “Now the technology is not in the code anymore; it is in a visual layer. The next step is that the visual layer matters less and less. It becomes a business question.” The plumbing keeps fading into the background, and the strategic decision keeps moving to the front.
AI is where that becomes concrete. The promise is that models and agents will act on business data: answer a question about stock, trigger a reorder, reconcile an invoice, prepare a report. That only works if the data underneath is complete, current, and permissioned, and if there is a record of what moved where and why.
An organization whose integration logic lives in one developer's head cannot give an AI system reliable access to its own operations. It also cannot audit afterward what that system actually did. AI does not remove integration dependency. It raises the price of it. The businesses that will get real value from AI are the ones that made their data flows visible and governed before they needed to. A governed integration layer is now a foundation rather than a convenience.
Businesses that see this early gain room to move. They can adopt new systems, respond to the market, and put their data to work without rebuilding the foundation every time. Those that keep rebuilding custom integrations inherit the same integration dependency their predecessors did, and pay for it in the one currency no business gets back. Unwinding it later runs through a phased legacy system migration.
Where your integration logic lives today
The shift in how businesses connect their systems comes down to a single change in what they are trying to buy. For years the goal was a working connection. The goal now is the freedom to change without asking permission from the past. Those are not the same thing. The difference is the dependency itself. It sits with the builder who holds the knowledge, with the systems tangled too tightly to separate, and with decisions made years ago that no one dares revisit.
None of those dependencies announce themselves. They sit quietly inside a landscape that still runs. Then a key person leaves, an investor asks a hard question, or a market shift demands a change the architecture cannot absorb. By then the cost is no longer theoretical. The difference at that point is stark. A business that made its integration logic visible and governed can move. One that did not can only watch.
The practical starting point is smaller than it sounds. Map where your integration logic actually lives, and ask who could change it tomorrow if the person who built it were gone. That single question surfaces the dependency most businesses have stopped noticing, and it turns an invisible risk into something you can act on. Removing it does not require ripping everything out at once. It requires deciding, deliberately, that the next connection you build will not be one more thing only one person understands.
Integration was never the hard part. What you are left with afterward is. The businesses that act on that now are the ones that will still be able to move when it matters.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
