Integration backlogs never shrink because shipping an integration creates an ongoing maintenance obligation instead of a completed project. Unseen operational drag (API changes, schema updates, and custom adjustments per customer) creates a second backlog that can consume up to 70% of engineering capacity.
Your product team finally clears a major integration off the roadmap. Everyone celebrates. Engineering lays out the next sprint for the core product.
Then Monday rolls around with two new integration requests. Meanwhile, the integration you just shipped starts throwing edge-case authentication errors, and engineering has abandoned the sprint to figure things out.
This is a too-common issue. No matter how fast the team builds, it seems that the backlog never gets shorter.
Most of the time, this isn't a capacity problem or a prioritization failure. Instead, it grows out of thinking that a shipped integration is "done." However, when your team ships an integration, it's created a long-term obligation – something that's often not factored into the integration cost.
The illusion of "done"
There's an understandable tendency to treat a shipped integration the same way you'd treat a shipped feature. The ticket closes, the PR merges, and the customer activates. Everything is good.
Standard product features work this way. Integrations, not so much.
A standard product feature is relatively self-contained. An integration, by definition, has a dependency on at least one system you don't control. The moment it ships, the future is certain. You will need to deal with breaking changes, deprecated endpoints, and expired auth tokens. None of that is immediately visible, but it's no less real.
The initial build (the authentication, the data mapping, the happy-path testing) is just the tip of the proverbial iceberg. The below-the-surface costs are substantial.
And, when you ship a custom, in-house integration, you're obligating your team to manage infrastructure as data volumes scale, ensure backward compatibility when APIs change, build the observability that catches failures before customers do, triage support tickets when syncs break, and redesign connectors when the third-party releases a v3 of its API.
The perceived cost of an integration (engineer-weeks to ship) is typically dwarfed by the long-term costs (which can easily be a 3x multiple of the initial efforts).
Integration entropy is ever-present
The term "tech debt" implies a choice, a shortcut that someone consciously took. Integration entropy is different because it's what happens naturally to any connected system without active maintenance.
Four things drive integration entropy.
- API changes. Third-party APIs are living systems. Endpoints get deprecated. Authentication methods evolve. Rate limits change. Salesforce has a formal versioning cadence, but "versioned" doesn't mean "stable forever." HubSpot routinely restructures object schemas. Each integration is built against a specific API at a specific moment, and it can change at any time.
- Integration decay. Webhooks break because of updated schemas or a daily sync that ran cleanly for six months starts missing records because a field name changed. When these things happen, it's not that the integration fails. That is, the issue wasn't catastrophic and immediate. Instead, things decayed.
- Codebase bloat. Every customer wants an integration to work slightly differently. To make everyone happy, teams often write custom configurations and quick-fix modules on top of the base integration. Over time, what started cleanly becomes a web of special cases – an increasingly unstructured codebase that maybe only one engineer in the company understands.
- Dependency drift. The libraries, SDKs, and infrastructure your integration depends on will get old. Security vulnerabilities will be discovered. And the longer you defer updates, the more expensive they become.
So, is your team managing integration entropy proactively or reactively?
The maintenance multiplier
If integration entropy were linear, the math would be manageable.
Unfortunately, each new integration doesn't just bring its own ongoing obligations – it interacts with everything you've already built. A change to your data model affects multiple integrations. A shared dependency change needs to be tested across every integration it touches. A platform-level auth change affects every customer who has activated integrations.
Try this. Scale the individual costs out across the full catalog. If maintaining a single custom integration consumes just five percent of an engineer's weekly capacity, here's the burn:
| Integrations in production | Engineering capacity used |
|---|---|
| 5 | 25% |
| 10 | 50% |
| 20 | 100% (one full-time engineer) |
And that assumes costs scale linearly, which is unlikely. It's not uncommon for teams to spend 70% or more of their integration-related engineering time on maintenance, monitoring, and debugging rather than building new value. That's not sustainable in the long term.
Versioning often makes this worse. Your first enterprise customer needs the Salesforce integration to map fields like this. Your second needs the integration to map fields like that. Your third is on a different Salesforce version. You now have three versions of the same integration in production, each with its own maintenance obligations. The decisions you make for version 1 influence every one that follows. A backward-compatibility decision on version 3 (made under deadline pressure) is a constraint you'll carry for years. The first integration costs you a sprint. By the twentieth, you've sufficient integration fixes in the queue to keep an engineer fully occupied for the indefinite future.
Two backlogs, one team
For most B2B SaaS teams, two backlogs run in parallel, and only one is visible. The visible backlog is the one on your roadmap. It consists of new integrations from sales and customer requests that made it into planning. That's the one leadership looks at, and the one that generates pressure.
The other backlog is hidden. But it's no less critical. This one includes everything necessary to keep existing integrations alive: API deprecation work, connector rebuilds, version migrations, security patches, and engineering escalations. This backlog doesn't show up on the roadmap, and it doesn't have owners or due dates.
This backlog relationship is hard to break. Your team ships integrations, adding to the hidden backlog. The hidden backlog absorbs capacity. The visible backlog gets even larger. Leadership asks why your team isn't shipping more. Your team ships more to reduce the visible backlog, which adds to the hidden backlog, which absorbs more capacity.
Working harder will not, cannot, fix this. Hiring more engineers won't fix it either. You cannot practically throw enough people at this maintenance issue because the architecture itself wasn't designed to scale.
The backlogs keep growing because every new integration adds future work faster than it removes current demand.
This is primarily a structural problem
The integration backlog doesn't grow because your team isn't working hard enough. It grows because custom-built integrations with corresponding maintenance are structurally incapable of scaling.
Every custom integration is a product your team owns. It's not just the initial build, but the auth flows, retry logic, logging, upgrades, and the eventual retirement plan.
While we are on the topic, retiring integrations is often harder than shipping them, because of that one customer who is still using the one you want to turn off.
When your devs are spending their days on Salesforce rate limits or HubSpot webhooks, they are probably not building the features that you need to differentiate your product. The more in-house integrations (integrations with a custom infrastructure) you ship, the more maintenance is required, and the less capacity your team has for the features that matter.
The teams that break out of this cycle don't do it by working harder. They do it by changing the foundation. An embedded integration platform like Prismatic handles the infrastructure that previously generated the hidden backlog (auth management, retry logic, versioning, monitoring, alerting, and customer-facing configs) so your team can focus on integration logic that delivers value. When a third-party API changes, you update the relevant component, and it propagates across every integration in your catalog that needs it rather than requiring manual intervention across dozens of customer-specific implementations.
Given the nature of integrations, the hidden backlog won't entirely disappear. But when the platform absorbs the operational overhead of keeping integrations running reliably, the hidden backlog stops being the thing that makes the visible backlog impossible to close.
What to ask before the next integration makes the roadmap
The question isn't "Can we build this?" It's "Are we prepared to own it from here on out?"
Before each new integration request gets approved, you should know:
- Who is accountable for this integration's health after go-live? Not who receives the alerts, but who is responsible for resolving the issues they identify?
- What happens when a third-party API changes? What's the process for getting ahead of a deprecation before customers start reporting failures?
- How many versions of this are you prepared to maintain simultaneously, and what's the threshold at which you stop supporting an older version and force a migration?
- Six months from now, what adoption rate and support-ticket volume will tell you that this integration is earning its place in the catalog?
These questions shouldn't slow down integration work. Instead, they lead to answers that separate teams that build sustainable integration programs from teams that spend years running in place.
Integration backlogs won't go away when every new integration adds more drag than lift. They will, however, stabilize (and often shrink) when the platform carries the weight of keeping integrations alive so your team doesn't have to.
If your team is feeling the weight of a growing integration catalog, or if you are moving into that territory, explore our docs or start a free trial to see how Prismatic handles the operational layer so your team can focus on what moves the product forward.
