True Cost of Building Integrations In-House

The average enterprise runs 897 applications and connects just 29% of them, according to MuleSoft's 2025 Connectivity Benchmark. That gap is the whole integration problem, condensed into one number. Someone has to build the plumbing, and most teams price it like a one-time project when they should be pricing it like a mortgage: a fixed thing up front, then payments for years after.

Here's the part that trips people up. Integration work isn't a backlog item you clear and move past. Every new tool signed, every enterprise deal that needs a specific connector, every feature that happens to require three more APIs wired in, adds to the pile permanently. B2B SaaS companies field 12 to 15 integration requests per quarter, and the queue refills about as fast as engineers can drain it. The real question isn't how a team finishes one integration. It's how the team carries this obligation forever. Most build-vs-buy conversations never get that far.

What an integration actually costs to build the first time

Sticker price depends on complexity, and the range is wide enough to be almost useless by itself. Simple integrations run $2,000 to $30,000. Moderate ones, the kind with multi-step workflows and real data volume, land at $15,000 to $40,000. Advanced work (real-time bidirectional sync against a legacy system, strict security requirements) climbs to $50,000 to $150,000 or more.

Time drives the real cost more than tooling does. A single CRM or HRIS integration, done properly with authentication, error handling, data mapping, and QA, takes a senior engineer 4 to 8 weeks. At a fully-loaded cost of $150,000 to $200,000 a year, that's $25,000 to $65,000 just to reach production. Hiring it out doesn't fix this, it just moves the number around: a mid-level U.S. backend developer runs roughly $72 an hour, but agencies charge $150 to $250 an hour for the same scope. Same integration, wildly different invoice, same amount of work underneath it.

None of that covers maintenance, security, or monitoring. Those arrive later as separate bills, and the build price only ever covers the moment the thing ships. Treating it as the whole number is where the estimate breaks before the project even starts.

The annual maintenance bill that compounds with every integration added

Software engineering has a rule of thumb: annual maintenance runs 15 to 25% of the original build cost. Apply that to a $30,000 integration and the bill is $4,500 to $7,500 a year, forever, just to keep the thing breathing.

Now scale it. Ten integrations means $45,000 to $75,000 a year in maintenance alone, before anyone builds anything new. Budget 8 to 12 engineering hours per integration per year at the low end. One compliance platform running more than 100 integrations estimated close to 1,000 engineering hours a year going purely to upkeep. Cross 15 integrations and expect 1 to 2 weeks of engineering time per integration per year, which stacks up to 15 to 30 weeks annually. That's brushing up against a full headcount doing nothing but keeping old connections alive, which is a strange thing to staff for and an easy thing to forget you're staffing for.

The bill never shrinks, because providers don't hold still. APIs get new versions, endpoints get deprecated, authentication requirements shift, rate limits tighten, and none of it arrives with much warning. A vendor rotates an OAuth scope, renames a field, or gives 30 days' notice before killing an endpoint if the team is lucky. Each event is small on its own. Stack them across 15 or 40 connectors, though, and it becomes a standing tax on the roadmap, due every quarter whether anyone budgeted for it or not.

Run the numbers over three years and the gap widens further. A complex integration that costs $80,000 to build, carrying $15,000 a year in support, lands closer to $125,000 total. That's well above whatever number sat in the original project budget. Every new connector doesn't just add its own price tag, it raises the floor of what maintenance costs every year after that, permanently. Nobody puts that part in the kickoff deck.

What integration work actually does to engineering velocity

This cost never shows up on an invoice, which is exactly why it's the most underpriced line item in the whole exercise. MuleSoft's 2025 benchmark, drawn from more than 1,000 IT leaders worldwide, found engineering teams spend 39% of their time building and maintaining custom integrations instead of shipping roadmap features. That's not a rounding error. That's two out of every five working days gone to plumbing instead of product.

Do the sprint math and it gets uncomfortable fast. Say engineering, QA, product, and operations each burn 20 extra hours aligning on an integration-impacted release. That's 80 hours per release. At a loaded rate of $100 an hour, that's $8,000 gone before the release ships. Multiply across a dozen releases a year and it's $96,000 in unplanned drag, and that figure doesn't even count incident response, or the person quietly reconciling data at 11pm because a sync job failed silently overnight.

None of this appears in the original build proposal. It shows up later, as a delayed roadmap item, a launch that slips two sprints, a feature that never gets scoped because there wasn't time left to scope it. This is the layer that turns a "$30,000 integration" into something an order of magnitude more expensive. The real toll is competitive output that never got delivered, which is a much harder thing to put on a slide than a dollar figure.

Security, compliance, and the cost of an integration failure

Every API integration is a data pipeline running straight into a third party. That means OAuth token management, encrypted credential storage, and rate limit handling, none of it optional once real data is flowing through the pipe. IBM's 2025 report puts the average global cost of a data breach at $4.4 million. An integration security failure can land somewhere in that neighborhood, depending on what breaks and what was moving through it at the time.

Even short of a full breach, emergency break-fix work runs $150 to $250 an hour, and a real failure event typically eats 40 to 80 hours of unplanned incident response. Compliance adds its own quiet tax on top. Every integration that touches personal data, financial records, or a regulated system expands audit scope, and that scope doesn't get certified once and forgotten. It scales with however many connectors are live, which means it grows exactly when nobody's watching it grow.

That asymmetry is the whole point. Doing security right, routinely, costs real money every year, without exception. One breach, or one failed audit, can erase years of whatever the build decision was supposed to save in the first place. This layer almost never makes it into the initial proposal, and that's the failure, not a footnote to it.

How in-house integration projects tend to overrun their original estimates

The Standish Group's analysis of 50,000 technology projects found 66% end in partial or total failure. Projects that miss tend to run significantly over budget, over schedule, and deliver substantially less value than promised. Integration work doesn't get a pass here. Studies of BI projects have consistently found data integration costs to be a leading driver of budget overruns.

Why does integration expand so reliably? Every new system exposes more dependencies than anyone scoped up front, full stop. A finance workflow that looked simple on a whiteboard suddenly drags in tax logic, approval routing, customer hierarchy rules, and archive requirements nobody mentioned in the kickoff meeting. EHR integration in healthcare routinely turns out far more complex than the first estimate suggested; manufacturing integration work routinely consumes a disproportionate share of total project resources. Without hard stage gates, teams keep tacking on "must-have" flows until the timeline and budget both lose their shape, and by the time anyone notices, it's too late to walk back.

So whatever number an engineering team hands over as an estimate, it deserves to get stress-tested against these base rates before anyone treats it as reliable. History says it probably isn't. Betting the roadmap on being the exception is not a plan, it's a hope wearing a spreadsheet.

What it costs not to build: retention, revenue, and the long-tail problem

Skipping the build carries its own price, and it shows up in retention. Research on SaaS retention consistently finds that products with at least one integration see meaningfully higher retention, and that effect compounds as more integrations are added. Users with integrations enabled have been found meaningfully less likely to churn than those without. Those effects are large enough that walking away from an integration carries a real cost of its own, even with no engineering invoice attached to it.

Here's the long-tail trap, and it's a trap most prioritization frameworks walk straight into. No engineering team can justify six weeks of work on an integration that serves 3% of the customer base, yet that 3% might walk without it. Stack twenty niche requests, each covering roughly 3% of customers, and the aggregate retention risk gets real fast. Standard scoring still pushes every single one to the bottom of the backlog, forever, because none of them win on their own merits alone. That's the flaw: a framework built to rank individual requests can't see the total that never gets served.

Building is expensive, and it compounds. Skipping the build is expensive too, just in a currency, lost customers, that never shows up on an engineering budget line. The build-vs-buy decision matters precisely because it decides which approach actually covers more of that long tail without gutting the roadmap to do it.

How to run an honest build-vs-buy calculation

Most teams run this math: engineer hours times hourly rate equals build cost. Done, ship it, move on. That number undercounts the real obligation by a predictable multiple, and it's the single biggest reason these projects come in over budget. The fuller version is build cost, plus annual maintenance times however many years the integration stays in production, plus the opportunity cost of engineering time pulled off the roadmap, plus security and compliance overhead, plus a buffer for the overrun that history says is coming.

Stack it for one moderately complex integration over three years. Build costs $15,000 to $40,000. Annual maintenance at 15 to 25% of build runs $2,250 to $10,000 a year, compounding as more integrations join the catalog. Diverted engineer time is harder to pin to one figure, but it needs pricing at the loaded engineering rate for every hour it consumes, not waved off as a soft cost that doesn't count. Security and compliance overhead varies by project but is never zero. Add it up honestly and the realistic three-year total often lands at two to three times the original build estimate. That gap is exactly what sinks the projects covered above.

On the buy side, embedded iPaaS platforms and unified APIs exist specifically to absorb the maintenance and security layers that make in-house ownership expensive. Buying a connector means buying the maintenance obligation, the security posture, and the ability to say yes to long-tail requests without pulling an engineer off the roadmap to do it.

In-house still earns its keep in three specific cases: a genuinely proprietary data model with no standard connector available, an integration that's an actual competitive differentiator rather than commodity plumbing, or a team with dedicated integration engineering already staffed and funded. Outside those cases, the honest question was never whether a team can build it. Almost any team can build almost anything, given enough sprints and enough patience from sales. The question is what it costs to own for three years, and what doesn't get built while someone's busy owning it.