Leadership

The Real Cost of Integration Rework in Midmarket Teams

Integration maintenance consumes a large share of engineering capacity, but almost none of it is tracked as such. How to measure what it costs you, and how to make the number credible.

The cost that was never budgeted

Every integration is justified once, as a project, with a build estimate. None is justified with a maintenance estimate, and the maintenance is permanent. A team that adds six integrations a year accumulates a maintenance baseline that grows monotonically while headcount does not.

Published research consistently finds that a large share of developer time goes to integration and maintenance work rather than to new product capability. The precise figures vary by survey and should be treated as directional rather than exact, but no credible study puts the number low, and every engineering leader who has measured it internally has found it higher than they expected.

Four components, three of them invisible

1. Incident response (visible)

The hours spent diagnosing and fixing a broken integration. This is the only component that reliably gets logged, and it is typically the smallest.

2. Detection and context reconstruction (invisible)

The time before the fix: noticing, correlating, working out whether this has happened before, finding who dealt with it last. For a recurring fault with no written history this frequently exceeds the repair time, and it is almost never recorded as integration work: it looks like ordinary investigation.

3. Vendor chase (invisible)

Composing escalations, following up, re-explaining to a new agent, verifying a claimed fix. Spread thinly over weeks, so it never looks like a meaningful block of time, and it falls on senior engineers because it requires context.

4. Downstream operational rework (invisible, usually largest)

The manual reconciliation, re-keying and spreadsheet maintenance that exists because two systems disagree. This lands on finance, support and operations rather than engineering, which is precisely why it never enters an engineering cost model. See SaaS-to-SaaS integration breakage.

Making the number credible

Engineering leaders asking for investment here usually fail for one of two reasons: the number is an aggregate that nobody can verify, or it rests on an hourly rate assumption that invites argument about the rate rather than the problem.

What works better:

• Per integration, not in total. "This one connection generated forty-one tickets and nine vendor escalations in two quarters" is concrete and checkable.
• Count events, not hours. Occurrence counts are observed; hours are estimated and therefore disputed.
• Include the operational side. The finance team's month-end reconciliation is the most persuasive element and the one engineering leaders routinely omit because it is not their cost centre.
• Show recurrence. A fault that has recurred six times after being marked resolved three times makes the case on its own.

What reduces it

In rough order of return for SMB and midmarket teams: eliminating recurrence through proper incident records; reducing detection time through correlation rather than more alerting; moving authentication to service accounts; negotiating breaking-change notice at renewal; and retiring integrations nobody can justify, which an inventory usually reveals several of.

The common thread is that the expensive part is not repair: it is everything surrounding repair. That is the premise Traxivo is built on.

Presenting it to people who hold the budget

Engineering leaders usually lose this argument for presentational reasons rather than factual ones. What tends to work:

• Lead with one integration, not the estate. "This connection generated forty-one tickets and nine escalations in two quarters" is checkable. An aggregate is not.
• Count events, do not estimate hours. Hours invite an argument about the hourly rate, which is an argument you cannot win and did not want to have.
• Include the cost borne outside engineering. The month-end correction in finance is the most persuasive element and the one engineering leaders routinely omit because it is not their cost centre.
• Separate recurrence from first occurrence. Repair is irreducible. Rediscovering a fault you have already solved three times is not, and that distinction is what makes the ask sound like engineering rather than complaint.

Close on what gets bought back: the roadmap items that slipped, named. Capacity in the abstract does not compete well against a feature with a customer attached to it.