The argument for best-of-breed software procurement has always been compelling. Instead of buying a single platform that does everything adequately, you buy the best CRM, the best ERP, the best inventory system, the best HR tool. Each is class-leading in its category. Each is constantly being improved by a vendor whose entire company depends on that product being better than the competition. You avoid lock-in. You retain flexibility. You get the best.
There is a system this argument forgets to account for. It is the one that gets built somewhere between the third and fifth SaaS subscription, usually by a developer who was supposed to be doing something else. Nobody budgeted for it. Nobody scoped it. Nobody gave it a name. It has no product manager, no roadmap, and no documentation beyond a README that was accurate in 2022.
This is the SaaS layer nobody asked for, and in many organisations it has quietly become the most critical piece of infrastructure they run.
How it starts
The trigger is always a report that cannot be produced. Sales data lives in the CRM. Revenue lives in the accounting software. Inventory lives in the warehouse management system. Someone senior wants a single view — orders, costs, margins, stock levels — and none of the three systems can produce it alone.
The first response is to export CSVs and combine them in a spreadsheet. This works. It works well enough that the spreadsheet becomes a weekly artefact. Someone's Friday afternoon is permanently reserved for running it. When that person leaves, the knowledge of which columns to pull and in what order travels with them.
Eventually someone replaces the spreadsheet with a script. The script runs on a schedule. It pulls from the CRM API, pulls from the accounting API, pulls from the warehouse API, joins the data, and writes it somewhere everyone can see. This is a marked improvement. It is also, without anyone having decided so, the first component of a data integration platform that the organisation now depends on.
How it grows
The script solves the reporting problem. But once it exists, it becomes a surface for new requests. The order confirmation email should include the inventory status from the warehouse system. The CRM should be updated automatically when an invoice is paid. When a customer is flagged as high-risk in the ERP, the sales team should see that flag in their CRM dashboard.
Each of these is a reasonable ask. Each requires reading from one system and writing to another. The developer who built the original script adds the logic. Then adds more. The script becomes a service. The service gains configuration. The configuration gains complexity. At some point it becomes something that takes more than fifteen minutes to explain to a new engineer.
Organisations that track software spend carefully often find that this internal layer — unbudgeted, unlicensed, unnamed — is doing more actual business logic than several of the SaaS products it connects. Customer lifecycle rules. Pricing adjustments. Fulfilment triggers. Compliance holds. The purchased software handles the storage and the UI. The glue layer handles the decisions.
The problem with glue
Glue code has a property that is easy to overlook when there is not much of it: it is load-bearing in proportion to how many things it connects. A single integration between two systems is a convenience. Five integrations between six systems is infrastructure. Remove any component and multiple business processes stop.
Infrastructure requires treatment as infrastructure. It needs uptime monitoring. It needs alerting when something fails silently. It needs versioning, so that when an upstream API changes, you can test against the new version without breaking production. It needs documentation that a new engineer can read and understand without shadowing the person who built it. It needs someone who is responsible for it on a Sunday morning when an order processing job stalls and the operations team cannot ship.
Most internal SaaS layers have none of these things, because they were never intended to become infrastructure. They grew into it accidentally. And because they were never deliberately designed, they carry every shortcut taken during the fourteen months of feature additions that followed the original Friday-afternoon script.
What the vendors do not tell you
Enterprise SaaS vendors have a term for the category of software that competes with the internal glue layer: iPaaS, integration platform as a service. Zapier is the consumer version. MuleSoft, Boomi, and Workato are the enterprise versions. The pitch is that instead of building your own integration layer, you buy a managed one.
This solves some of the infrastructure problem. iPaaS platforms handle uptime, versioning, and monitoring. But they do not solve the design problem. An iPaaS platform built on top of a poorly understood data model — where the same customer record exists in three systems with three different identifiers — will fail in exactly the same ways as a homegrown script built on the same foundation. The platform is better engineered. The business logic is still wrong.
The vendors also do not advertise how quickly the cost of an iPaaS subscription scales with the complexity of what you are integrating. A simple trigger-action workflow costs almost nothing. Bidirectional synchronisation across five systems with conditional logic, error handling, and custom transformations costs substantially more, often more than any single SaaS product it connects. At that point the question of whether to buy or build becomes genuinely interesting again.
The design decision hiding inside a procurement decision
Best-of-breed procurement is not wrong. There are genuine cases where the right answer is to buy the best product in each category and accept the integration work that follows. Organisations with unusual needs in a single domain — a specialist logistics operation, a research institution with specific data requirements — often cannot find a single product that handles their core domain well. Best-of-breed is the right call.
But it is a design decision, and it needs to be made as one. The integration layer is not overhead that happens after the procurement decision. It is a system that will be built as a consequence of the procurement decision, and it needs to be budgeted, staffed, owned, and designed with the same rigour as any other system.
The organisations that handle this well do not discover their integration layer by accident. They define it deliberately: here are the systems we are buying, here is the data we need to move between them, here is the team responsible for the infrastructure that moves it, here is how we will know when it breaks. The glue becomes architecture.
The organisations that handle it poorly end up with a critical system that nobody owns, running on a server that nobody is monitoring, doing business logic that nobody has written down. They find out it exists when it stops working.
Best-of-breed plus accidental integration layer is not, in practice, best of breed. It is best of breed in the parts you evaluated, plus whatever was cheapest to build at the time in the parts you forgot to evaluate. Understanding that before the procurement decision is the difference between a considered architecture and an expensive surprise.