The short answer
The layer is the small piece of software that sits between the tools you bought: it moves data from one to the other, holds the rules about what happens next, and shows people one screen instead of five. It usually has four parts: connectors to each tool, a small database that knows which customer or order is which in every system, the business rules with a review queue for anything unusual, and alerts when something fails.
It is not a new ERP and it does not replace your CRM. Your accounting stays in the accounting software. The layer just stops people from being the integration. In Build or buy software? we argued for buying the tools and building the layer. This piece is about what that layer is made of, and what makes a good one.
Why do you need one at all?
Because the tools rarely talk to each other. The 2025 MuleSoft Connectivity Benchmark, a survey of more than 1,050 IT leaders, found that the average large organisation runs 897 applications and only 29% of them are integrated. 80% named data integration as their most significant obstacle.
A company of 30 people runs ten or fifteen tools, not 897, but the share is similar. Orders arrive by email and get typed into the ERP. A deal closes in the CRM and someone creates the invoice by hand. The weekly report is built from three exports. Each gap is small. Together they are often a full-time job nobody was hired for.
What is the layer made of?
Four parts, each small on its own.
A typical layer for a small company connects two to five tools. It is closer to the size of an integration than of a platform.
The second part is the one most no-code flows lack. Without a shared record, every flow has to work out again which customer is which, duplicates creep in, and nobody can answer "did this order reach accounting?" without opening both systems.
It should own the rules, not the data
A good layer is thin. Customer data lives in the CRM, invoices in accounting, stock in the ERP. The layer stores only what it needs to connect them: IDs, statuses and a log. The moment it starts holding its own copy of everything, you have built a second ERP, and two sources of truth are worse than one.
Thin also means replaceable tools. Structured e-invoices between Latvian companies become mandatory from 2028, and many companies will change or upgrade their accounting software before then. If the connections live in one layer, you change one connector. If they live in a dozen personal automations and spreadsheets, you find out which ones broke when the invoices stop.
It must fail loudly
A manual process fails visibly: someone forgets, and someone else notices. An automation that fails quietly is worse than no automation, because everyone assumes the data is there. Every sync should be logged, failures should retry and then alert a person, and anything the rules cannot decide should go to the review queue.
This is the clearest difference between a layer and a collection of quick flows. When we build automations and integrations, the error alerts to your chat are part of the first version, not a later improvement.
You should own it
The layer ends up holding your company's operating rules: how orders are checked, who approves what, which customer gets which price. That is not something to rent from a vendor who might change their pricing or close. The code should be in your repository and the data in your systems or an EU-hosted account in your name, so another developer can take it over if they ever need to.
When you can skip the layer
If two tools have a native connector, the volume is low and nobody minds checking it by hand now and then, use the connector or a no-code tool such as Zapier, Make or n8n. The layer pays off when three or more tools share the same customers or orders, when mistakes cost money, or when the same data is typed in more than once a day.
The fastest way to see whether you need one is to draw the process and mark every place where the same information is typed twice. How to map a business process in one afternoon shows how.
