Integration is product

The modal mid-market business runs on between 30 and 60 SaaS products. CRM, ERP, billing, support, marketing automation, document storage, identity, scheduling, payroll, analytics, security, observability. The portfolio is the result of two decades of best-of-breed buying, where each tool was the right answer to the question someone asked at the time.

The collective is not the right answer to anything. The same data lives in five places and disagrees in three of them. People spend their days copying numbers from one tab to another. The integrations that exist are partial, asynchronous, and break quietly when either vendor changes an API. The cost of this friction is enormous and almost never measured.

The middleware nobody wants to build

The work that fixes this is the work nobody wants to build. There is no logo to ship, no demo to show, no announcement to make. It is plumbing — webhook listeners, sync jobs, custom APIs, transformation pipelines, dead-letter queues, idempotency keys. It is engineering work in the most boring sense of the word.

It is also, in our experience, the single highest-leverage thing a software team can do for a mid-market client. Not new product. Not AI. The reliable, observable connection of three or four systems the client already pays for.

Most mid-market companies don't need new tools. They need the tools they have to talk to each other.

Why integration platforms aren't enough

The obvious objection is that this is a solved problem. Workato, Tray, Zapier, n8n, Boomi — the integration platform space is large, well-funded, and full of capable products. They are excellent for the simple cases. They struggle with the cases that matter.

The cases that matter are the ones with business logic. Routing an invoice based on the supplier, the amount, the project code, and a lookup against an internal vendor classification list is not a workflow that fits cleanly into a node-and-edge canvas. It is a small, real piece of software. It needs version control, tests, code review, and a deployment process. The integration platforms are built for the cases where the logic is "copy this field to that field." They are not built for the cases where the logic is the product.

Treat it like product engineering

The discipline that works is to treat integration like product engineering. The integration is not a side-project, not infrastructure, not glue. It is software that runs in production, owned by the same standards as everything else — written tests, observability, an on-call runbook, a clear contract surface, versioned APIs.

When you do this, the operational impact is immediate and measurable. Manual data entry vanishes. Reporting becomes accurate. Support response times drop because the support tool actually knows what the customer bought. The team stops spending an afternoon a week reconciling spreadsheets. The work is invisible from the outside — nobody photographs an idempotency key — but it shows up in every operational metric the business runs on.

Integration is product. Build it that way.