Integration Software as a Service: Do You Need a Platform?

Integration software as a service is a category name for hosted tools that connect your systems to each other. The pitch is always the same: you have a dozen pieces of software that do not talk, this platform makes them talk, here is a licence fee.

Sometimes that is exactly right. Often it is an expensive answer to a problem that had a cheaper one, and the reason firms overbuy is that the licence gets chosen before anyone has counted how many connections they actually need.

Here is what matters most:

• Count your connections before you shop. Three or four does not justify a platform. Twenty does.
• The recurring question is not features, it is how the price behaves when the volume grows.
• Where your data passes through during transfer is a decision you make once and live with.
• The slow part of your process is almost always the gap between two systems, not either system.
• Whoever maintains the connections matters more than which platform hosts them.

What the category actually covers

Three quite different products get sold under this name, and the first thing worth doing is working out which one you are being shown.

Connectors. Pre-built links between common software, so your form tool can write into your accounting package without anyone building anything. Fast to start, limited to what the vendor has built, and priced per use or per connection.

A build environment. A place to construct your own connections with logic in between: transform this, check that, route the other. More capable, needs somebody who can build, and this is where most real business processes end up living.

A managed data layer. Moving large volumes between systems on a schedule, with history and reconciliation. This is a different problem from the first two and usually a different budget.

A vendor selling you the third when you needed the first is the most common way firms end up with a licence they use four percent of.

The four questions that decide it

How many connections do you actually need? Write them down. Not the ones you might want in two years, the ones that are costing you time this month. Under about five, a platform licence is usually the most expensive part of the solution and you would be better served building those connections directly. Above fifteen or twenty, the management overhead of doing it yourself starts to justify a platform that gives you one place to see everything.

How does the price behave at ten times the volume? This is the question that catches people out. Some of these tools bill per operation, which means the invoice grows in proportion to how successfully you automate. That is fine while you are testing and unpleasant once the thing is load-bearing. A process with five steps often counts as five billed operations rather than one, so cost tracks how thoroughly you automated rather than how much work you removed. Others charge per server or per seat, which stays flat as volume rises. Neither model is wrong. Not knowing which one you signed is.

Where does the data pass through? For anything client-confidential this usually settles the architecture before anything else. A hosted platform means your records travel through a third party's environment, and whether that is acceptable is a question for whoever owns your security posture. Running the connections inside your own cloud account keeps the data in your control and means you keep the system if the vendor relationship ends. It also means somebody must own that infrastructure, which is a real ongoing job and not a footnote.

Who maintains it in eighteen months? Connections break. An upstream system changes something, a login policy rotates, a field gets renamed. If no named person owns watching for that, the connection fails quietly and you find out from a client.

The failure nobody demos

Worth spelling out because it is the most expensive thing that happens with these tools, and it happens on every one of them.

When a step in a connection fails, what happens next is something somebody configured. It is entirely possible to build a connection that reports success while moving nothing. We have done it to ourselves. One of our own lead-capture connections was pointed at a spreadsheet tab that did not exist. Every single run recorded as successful. Not one row was ever written, and nobody noticed for six weeks, because the monitoring watched whether the run completed rather than whether the data arrived.

A second one was worse. An outbound pipeline was sending through a service whose account balance had run out. The service returned an error every time. Because that step had not been set to treat the response as a failure, the system recorded 11,458 messages as sent when every one had died at the far end. The dashboard was green throughout.

Neither is an exotic bug and neither is specific to a platform. Both are configuration choices. Which is why the platform decision is maybe a quarter of your outcome, and who builds and watches it is the rest.

So add a fifth question: what does this alert on, and does it check the outcome or just the run? A connection that verifies the record it wrote can be read back is a different class of reliability from one that reports completion.

Where the time actually goes

Most firms assume a process is slow because the steps are slow. Time one honestly and the steps often take two hours of real work spread across nine days. The rest is the work sitting in a queue between systems, waiting for a person to move it.

That is why connecting systems pays better than optimising either of them. The saving is not the typing, though the typing is real. It is the queue disappearing.

It also explains why automating one connection rarely changes the end-to-end number. Remove one handoff from a seven-handoff process and the work still waits, just somewhere else. If the goal is turnaround time rather than labour hours, you have to go after the whole chain.

Sizing it honestly

Count the connections you need. For each, estimate how many times a month somebody moves information by hand across that gap, and how long it takes including the checking. Multiply by a fully loaded hourly cost.

Four connections, each handled forty times a month at eight minutes, is about twenty-one hours a month. At forty dollars an hour fully loaded, roughly eight hundred and fifty dollars a month. Against that, a platform licence plus build cost may or may not make sense, and now you can tell which.

Then compare the two shapes properly. A platform gives you one place to manage everything and a recurring fee that may scale with use. Direct builds cost more upfront per connection and little to run, but you own the maintenance. At four connections the second usually wins. At twenty-five the first usually does.

FAQ

What is the difference between integration software and workflow automation?

The distinction is mostly marketing and the products overlap heavily. Integration tends to describe moving data between systems reliably, sometimes at volume, while workflow automation describes moving work through a sequence of steps with logic and people involved. Most real projects need both, and a proposal that presents them as two separate purchases is usually describing a price list rather than a technical boundary.

Do we need this if our software already has built-in connections?

Often not, and it is worth exhausting that option first. Many business tools ship with connections to the other common tools, and a meaningful share of the integration requests we see are already available as a setting nobody switched on. Check what you already own before evaluating a platform. The built-in version is free, supported by the vendor, and does not add a party to your data path.

How long does an integration project take?

A single connection between two well-behaved systems is usually days to a couple of weeks, and most of that time goes into the edge cases rather than the connection itself. A chain covering a whole process is a project of weeks. Estimates that assume clean, consistent data are the ones that overrun, because real data has duplicates, blanks and records that do not match across systems.

Should we self-host or use a hosted platform?

Self-hosting keeps client data inside infrastructure you control and means the system survives the vendor relationship, which is why document-heavy and client-confidential work tends to end up there. The cost is that patching, backups and monitoring become somebody's named responsibility. Hosted removes that work and adds a third party to your data path. Decide it before you have twenty connections built, because moving later is a rebuild.

Key takeaways

• Count the connections you actually need before evaluating a platform. Under five rarely justifies a licence.
• Some of these tools bill per operation, so the invoice grows as the automation succeeds rather than as work is removed.
• Any integration can be configured to report success while moving no data, so monitor the outcome rather than the run.
• The delay in most processes sits in the gap between two systems, not inside either one.
• Where data passes through during transfer is an architecture decision that is expensive to reverse later.

If you have a list of systems that do not talk and want a straight read on whether that needs a platform or four direct builds, that is a short conversation.

Book a free strategy call

Related reading: make vs n8n vs zapier · what is workflow automation · do you need an AI automation consultant

Services: system and data integration · n8n automation services