In most companies there is a person whose real job, if you watched them for an hour, is to move data from one screen to another. An order comes into the e-shop; they type it into the ERP. An invoice is raised in accounting; they update the CRM by hand. Nobody planned this job — it accreted, one system at a time, because each tool was bought to solve its own problem and none of them was bought to talk to the others. The re-keying feels like just how things are. It is not. It is the visible cost of a missing integration, and it is more expensive than it looks.
The real cost of swivel-chair work
The industry name for this is swivel-chair integration: a human being is the connection between two systems, literally turning from one screen to another. The obvious cost is the hours, and they add up faster than anyone budgets for. The larger cost is quieter. Every manual re-key is a chance to transpose a digit, pick the wrong customer, or miss a row entirely, and those errors surface days later as a wrong invoice or a shipment to the wrong address, when they are far more expensive to fix.
Then there is the cost you never see on any line: the data is always slightly out of date, and slightly disagreeing with itself. The CRM says one thing, the ERP another, because the human bridge between them ran yesterday and not today. Decisions get made on numbers that are almost right, which is often worse than numbers that are obviously wrong, because no one thinks to question them.
There is a human cost too, and it is worth naming. Swivel-chair work is soul-destroying to do — a capable person spending their day as a copy-paste machine is a capable person quietly deciding to leave. You are paying a skilled salary for a task a computer does perfectly and a person does resentfully. When the re-keying finally gets automated, the reliable second benefit, after the errors disappear, is that the people who were doing it go back to work that actually needs a human.
Point-to-point spaghetti versus a hub
The first integrations a company builds are usually point-to-point: connect the e-shop directly to the ERP, then the ERP directly to accounting, then the CRM to two of the others because someone needed it. Each connection is reasonable on its own. Together, after a few years, they are a web where everything depends on everything, no one can change a system without breaking two others, and a single field rename sets off a week of firefighting.
The alternative is a hub: instead of every system wiring directly to every other, they connect through a central integration layer that owns the routing and the translation between them. It costs more to set up than the first point-to-point link and far less than the tenth. The test for which you need is simple — with two or three systems, point-to-point is fine and a hub is over-engineering. Once you are connecting five or six and each new one multiplies the connections, the spaghetti is already forming, and a hub is what stops it.
The deeper value of a hub is that it makes systems replaceable. When every connection runs through a central layer, swapping your old CRM for a new one means rewiring one link to the hub, not tracing and rebuilding the six direct connections that CRM had grown. Point-to-point spaghetti quietly welds your systems together, so that a tool you have outgrown becomes impossible to remove without breaking things you forgot were attached to it. A hub keeps each system at arm's length, which is exactly what lets you change your mind later without a rebuild.
Off-the-shelf iPaaS versus custom integration
You do not always need to build. Tools like Zapier, Make and their peers — the category is called iPaaS — let you connect common systems with pre-built connectors and no real code, and for a great many needs they are exactly right. If you are moving standard data between popular tools, on a schedule, with simple rules, an off-the-shelf platform will do it in an afternoon and you should not build anything.
They reach their limits in predictable places. When the logic gets genuinely complex, when the volume grows enough that per-operation pricing hurts, when you need guarantees about ordering and error handling that a visual tool does not give, or when one of your systems is bespoke and has no connector — that is where custom integration earns its cost. The honest rule: start with the off-the-shelf tool, and move to custom only when you hit a wall you can name. Reaching for a custom build on day one is as common a mistake as never outgrowing the no-code tool.
Decide the source of truth
Before wiring anything together, answer one question for each kind of data: which system is the authority? For a customer's address, is the CRM right or the ERP? For stock levels, is it the warehouse system or the e-shop? If two systems both think they own the same fact, they will disagree, and an integration that syncs both directions without a decided owner does not fix the disagreement — it launders it, copying each system's version over the other in a loop no one can follow.
So decide, per data type, the single source of truth, and let the others read from it. This one decision prevents more integration pain than any piece of technology. It is also the decision most often skipped, because it is a business conversation dressed as a technical one — and the business, not the tool, is the only place it can be answered.
Source of truth is decided per data type, not per system, and that nuance matters. The CRM might be the authority on a customer's contact details while the ERP owns their credit limit and the warehouse owns stock; one customer record is stitched from three owners, each authoritative over its own fields. Getting this map right up front is unglamorous work that feels like it is delaying the real integration, but it is the real integration — the wiring is just plumbing once the ownership is clear, and a nightmare when it is not.
Integrations fail quietly — plan for it
A user interface fails loudly: something breaks, a person sees it, someone gets called. An integration fails silently. A sync job dies at 3am, no human is watching, and the two systems drift apart for a week before anyone notices the numbers do not match. Building an integration is easy; building one that fails safely and visibly is the actual work, and it is where cheap integrations cut the corner that later costs the most.
Three ideas do most of the protecting. Data quality: validate at the boundary, because an integration that faithfully copies bad data just spreads the error faster. Idempotency: design so that processing the same message twice is harmless, because networks retry and duplicates are a certainty, not an edge case — a non-idempotent integration double-charges a customer the first time a message is delivered twice. And error handling: when something fails, it must be retried sensibly and, if it still fails, surfaced to a human loudly, never swallowed. An integration with no alerting is not finished; it is a silent failure waiting for a date.
This is the corner that separates a cheap integration from a sound one, and it is invisible on the day of delivery. A demo that copies one order across looks identical whether or not it handles the order that arrives twice, the field that comes through empty, the system that is down for maintenance. The difference only shows months later, at the worst possible moment, on the transaction you most needed to get right. When you commission an integration, the questions worth asking are not about the happy path — they are what happens when this fails, and how will we know.
APIs and webhooks, in plain terms
Two words come up constantly, and they are simpler than they sound. An API is a system's official front door for other software — a defined way to ask it for data or tell it to do something, so you are not scraping its screens or poking at its database. If a system has a good API, integrating with it is ordinary work; if it has none, integration means awkward workarounds, and that alone should weigh on which tools you buy.
A webhook is the same relationship in reverse: instead of you repeatedly asking a system whether anything changed, it calls you the moment something does. Polling an API every five minutes is asking are we there yet; a webhook is the system tapping you on the shoulder when you arrive. For anything that needs to feel immediate — an order flowing straight to the warehouse — webhooks are what make it happen without a human or a timer in the loop.
When to build a proper integration layer
Pulling it together: build a real integration layer when the re-keying has become a job, when you are connecting enough systems that point-to-point is turning to spaghetti, when an off-the-shelf tool has hit a wall you can name, and when the cost of the data being wrong or late has grown past the cost of doing it properly. Before all of that, simpler answers are usually the right ones, and reaching for a big integration platform early is its own expensive mistake.
The right first step is rarely to start building. It is to map what you have — which systems hold which data, where the manual bridges are, and what each broken sync actually costs you — and only then decide what to connect, in what order, and whether to buy it or build it. That map is a short piece of work, and it is the difference between an integration that quietly removes a class of errors and one that adds a new system to babysit.