How Many Engineers Does It Actually Take to Maintain 10 Integrations
Maintenance costs twice as much as building integrations, and complexity explodes exponentially.
Most engineers assume once an integration ships, it kind of just… runs. You built the thing, it works, on to the next ticket. That assumption is wrong, and it's costing teams more than they realize. In 2024, 52% of developers experienced a production crash because a third-party vendor pushed an unannounced breaking change. No warning. No migration period. Just a broken integration and an on-call alert at 11pm. The real cost of building and maintaining integrations isn't in the build. It's in everything that comes after. And when you're running ten integrations in production, that cost doesn't just add up — it multiplies, like a bug that reproduces faster than you can squash it.
What building a single integration actually takes before maintenance begins
Let's start at the beginning, before a single line of production code ships.
Build times for integrations vary more than most teams expect:
- Simple integrations: 1–2 weeks
- Moderately complex (auth, data transformation, error handling, QA): 3–6 weeks
- Highly custom or complex (real-time bidirectional sync, custom field mapping): 8–12 weeks or more
And 71% of developers in one study said a single product integration takes at least three weeks to build. Even the "simple" ones.
A basic two-way sync between your product and a single CRM. HubSpot. Salesforce. Doesn't matter. That alone typically takes four to eight weeks of focused backend developer time. At roughly $72/hour for a mid-level US backend developer (the 2026 average), a moderately complex integration runs somewhere between $10,000 and $50,000 just to build. Advanced integrations with real-time sync or custom field logic can exceed $150,000. Agency rates push that ceiling even higher.
Here's the part that gets people: those figures are just the entry fee.
Authentication setup, security review, monitoring infrastructure, and error handling are separate budget lines. Monitoring infrastructure alone can cost $5,000–$15,000 upfront if you want to do it properly. Security compliance features (HIPAA, GDPR, PCI-DSS, SOC 2) add another 20–40% depending on what your customers require.
The prototype phase feels tractable. You read the docs, wire up OAuth, map a few fields. It's satisfying. But that's maybe 10% of the total effort — the tip of the iceberg. The other 90% is the compounding operational debt you don't see coming until you're already in it.
How much engineer time one integration consumes after it ships
Here's a practitioner estimate that holds up pretty well in the real world: it takes roughly 150 hours to build one integration and about 300 hours to maintain it over its lifetime. Maintenance is twice the build effort. That's before anything goes wrong.
Annual maintenance benchmarks land at 15–25% of initial build cost on the conservative end. Experienced practitioners frequently put the real rate closer to 30%.
For a senior engineer at $150,000 in annual salary, the time spent on a single integration can represent close to $50,000 in internal annual costs. That's before customer support gets involved.
If your customer success team works through around 150 support tickets a year tied to one integration, and each ticket averages two hours to resolve, you're looking at a significant additional annual cost that never shows up in the engineering budget because it's buried in CS headcount.
The specific things forcing engineers back into a shipping integration:
- API endpoint deprecations (third parties do this constantly)
- Pagination schema changes that silently break data pulls
- New rate limits applied without notice
- Sync failures that customers discover before your monitoring does
- On-call incidents at off-hours pulling senior engineers out of deep work
- Every new customer onboarded becomes a new live test of every integration the team maintains
None of these are edge cases. They are the job. Maintenance isn't a background cost. It's a recurring claim on the most expensive people on the team.
Why complexity doesn't grow linearly when you move from one integration to ten
This is the part most teams don't think about until it's too late.
Point-to-point architectures scale quadratically. The math is n(n-1)/2 potential failure paths as systems multiply. That formula sounds abstract until you run the numbers:
- Connecting your fifth business system creates 10 integration connections
- Connecting your tenth creates 45 connections
- At 10 systems, you're looking at 100-plus potential failure paths
Meanwhile, your headcount has stayed flat. And each of those paths requires monitoring, alerting, and an owner.
Custom integration code is manageable for two or three integrations. Beyond that, the team is no longer just writing an HTTP client. They're maintaining a distributed systems state machine that has to handle network partitions, provider outages, and undocumented schema changes from partners who don't owe them a heads up.
According to New Relic's 2024 Observability Forecast, 29% of unplanned outages originate in a third-party or cloud-provider service. As your integration count grows, so does the blast radius when something fails.
This is the critical architectural point: integration overload is not a staffing problem. It is an architectural one. Each new system added multiplies the maintenance surface. It does not simply add to it.
That's why the answer to "how many engineers do we need" is never just a fraction of one person per integration.
The headcount math for maintaining 10 integrations at scale
Let's do the math directly.
Start with moderate complexity across all ten integrations. That's 200–400 engineer-hours annually in maintenance alone, before on-call work, ticket resolution, or monitoring attention. At a $150,000 annual salary baseline, that's roughly $14,000–$29,000 in direct labor. And that is the floor, not the ceiling.
Add support ticket load, monitoring overhead, and security compliance work, and the total annual personnel cost for a single integration climbs toward $50,000.
Multiply that across 10 integrations. The two-year total for ten in-house integrations runs between $500,000 and $1.5 million when you include maintenance, security, and opportunity cost. That's the realistic envelope.
As a reference point for what scale looks like: SaaStr has observed that at $10M ARR, SaaS companies with 20–25 engineers often carve out a team of roughly three to five people just for integrations, scaling, and infrastructure. Even at relatively early growth stages. And in manufacturing and distribution, 64% of organizations report legacy system dependencies consuming 16 or more hours per week in engineering effort. Effectively two full-time engineers doing nothing but keeping systems talking.
The honest answer to the headline question: for 10 integrations at moderate complexity and real production scale, teams realistically need one to two dedicated engineers at minimum. That number rises sharply as complexity, customer count, and compliance requirements increase. The enterprise version of this isn't one engineer. It's a full pod: a project manager, a business analyst, an integration architect, developers, and QA/DevOps.
How much of the total cost never appears on a project estimate
This is the uncomfortable part.
Initial development represents only 30–40% of the total cost of ownership for custom integrations. Maintenance, updates, and adaptations account for the remaining 60–70%. Forrester's Total Economic Impact model puts roughly 78% of lifetime software cost as accumulating after launch. Not during development. After.
And Forrester's Software Development Trends Report (2024) found that 67% of failed software implementations stem from incorrect build-vs-buy decisions, largely because teams underestimate the total cost of ownership. In other words, most teams are making this exact mistake at scale.
The line that never appears on any invoice is opportunity cost.
- Every hour a senior engineer spends on a connector is an hour not spent on differentiating product work
- Two engineers on integration maintenance for six months is roughly $150,000 in fully loaded salary costs redirected away from the core product
The survey data across multiple sources paints a consistent picture:
- MuleSoft's 2025 Connectivity Benchmark (1,050 IT leaders): 39% of IT team time is spent designing, building, and testing custom integrations
- Fivetran and dbt Labs (April 2026): 53% of enterprise engineering time goes to pipeline maintenance, representing a $21.6M annual productivity tax per 1,000-engineer organization
- Gartner: integration maintenance consumes 30% of IT's time in tool-heavy organizations
The pattern across all of these is the same. Teams consistently spend 30–50% of their engineering capacity not on new capabilities, but on keeping existing connections alive.
Customer success costs sit on top of that. Managing support tickets and troubleshooting client-side configuration errors adds another $15,000–$20,000 annually per integration channel to the personnel budget, conservatively.
What the organization looks like when integration debt goes unaddressed
There is a threshold organizations cross where integration maintenance time exceeds new feature development time. When that happens, the team is running to stand still — like a treadmill set just fast enough that you can never quite step off.
Data engineering teams at that stage spend the majority of their time addressing integration failures, updating connectors for API changes, and troubleshooting sync issues. Not building. Maintaining. That's the inversion point.
The backdrop makes it worse. 86% of IT leaders expect workloads to rise, with a projected 18% increase in projects from 2024 to 2025. Integration debt accumulates against rising demand, not stable demand. And the percentage of IT projects not delivered on time rose to 29% in 2024, up from 26% the year before. Late delivery and integration maintenance load are not unrelated.
The on-call problem is where it becomes visceral. Integration incidents pull senior engineers out of deep work into firefighting. Every new customer onboarded is a new live test of every integration the team maintains. The team borrows engineers from product work to fight integration fires, which delays product work, which creates pressure to ship faster, which means less time spent on integration quality. The cycle gets harder to exit as integration count grows.
Here's a number that illustrates how far most organizations are from having this solved: only 2% of organizations have more than half their applications connected, despite organizations using an average of 897 applications. The gap between what's connected and what needs to be connected keeps widening.
A dedicated integration sub-team is not a luxury at scale. It is what the math eventually forces.
Where the math changes and what teams have done about it
The build-in-house path has a known cost structure at this point. One to two dedicated engineers for 10 integrations, rising to a full pod as integrations and customer count scale, with a $500,000–$1.5M two-year total as the realistic envelope. That's the deal you're signing up for.
The architectural alternative is migrating from point-to-point architecture to a unified integration platform. Organizations that have made this move report 60–80% reductions in integration maintenance hours within three months of switching. Recovered capacity redirects to feature development.
A concrete example: Yoti, a digital identity platform, implemented an embedded iPaaS and saved 95% of the engineering time they had previously spent building, deploying, and managing integrations. That is not a marginal improvement. That is a structural change.
Pre-built, managed connectors shift the cost model entirely. The upfront connector cost replaces ongoing maintenance engineering. Auth handling, deprecation tracking, and monitoring become someone else's operational burden.
The honest tradeoff is worth naming directly. Managed platforms introduce vendor dependency, per-connection pricing, and limits on customization. Teams with highly specialized integration requirements or unusual data models will still face custom work. There is no version of this that is completely free.
The real decision is not build vs. buy in the abstract. It is whether the engineering capacity consumed by maintenance is the highest-value use of that capacity at the current stage of your product.
The question every team should answer before adding integration 11 is straightforward: what is the fully loaded annual cost of the 10 already in production, and is that the budget you want to double?
