Why We Stopped Building 'Integrations'. The Maintenance Hell That Added Zero Revenue.

We had integrations with 47 different tools. Salesforce, HubSpot, Slack, Asana, Monday, Notion, Zapier, and 40 more.

Building them took 18 months of engineering. Maintaining them took 2 FTEs continuously.

Then I checked usage.

12 integrations had more than 10 users. 35 had fewer than 5. Some had zero.

We were spending $400k/year maintaining integrations that, collectively, added no incremental revenue. Customers checked the "integrations" box during evaluation and then never used them.

We killed 30 integrations. Not a single customer churned.

Here's the integration trap — and how to escape it.

Section 1: The Integration Checkbox

Every B2B buyer asks: "What integrations do you have?"

The Sales Narrative:

Integrations help close deals. "We integrate with Salesforce!" means compatibility with their stack. It reduces perceived switching costs. It checks a box on their RFP.

Sales teams push for more integrations. "We lost a deal because we don't have HubSpot integration." So engineering builds HubSpot integration.

The integration count becomes a marketing asset. "50+ integrations!" sounds impressive.

The Reality:

Usage is massively lower than expressed "need."

Buyers say they need integrations. They put it in requirements. They ask about it on sales calls. Then they sign the contract.

And then... they don't use the integrations. Maybe they try the Slack integration once. Maybe they never set up the Salesforce sync. The "requirement" evaporates.

Why the Gap?

• Integration setup is work. Busy teams deprioritize it.
• The integration was aspirational: "We should connect these tools" vs. "We will connect these tools."
• The use case wasn't concrete. They imagined needing it without a specific workflow.

Integrations are evaluation checkboxes, not actual requirements.

Section 2: The Maintenance Nightmare

Every integration is a mini-product. And mini-products require maintenance.

APIs Change:

Salesforce updates their API. Your integration breaks. HubSpot changes their authentication flow. Your integration breaks. Slack deprecates a webhook format. Your integration breaks.

Each partner's roadmap becomes your risk. You have no control over when they change things. You just have to react.

47 Surfaces:

47 integrations means 47 surfaces to monitor, maintain, and fix.

When we had 47, something was always broken. Monday's API was down. Notion had a rate limiting issue. Asana changed their field formats.

Our on-call rotation included integration issues. Engineers spent nights debugging partner API problems.

Support Burden:

"Your Salesforce integration isn't syncing."

"Why aren't my HubSpot contacts showing up?"

"The Slack notifications stopped working."

Integration issues are support magnets. They're complex to diagnose. They often involve the customer's configuration on the partner side. Tickets take 3x longer to resolve.

The Compounding Problem:

More integrations = more maintenance = less time for core product = competitors catch up = sales asks for more integrations to differentiate = more maintenance.

The cycle is vicious.

Section 3: The Economics

We ran the numbers. The results were damning.

The Investment:

• 47 integrations: 18 months of cumulative engineering time to build
• 2 FTEs for ongoing maintenance: ~$400k/year fully loaded
• Support burden: Estimated 15% of support tickets related to integrations

Total 5-year cost: Well over $2M.

The Return:

We tried to attribute revenue to integrations. It was impossible.

We couldn't find a single signed contract where the customer explicitly said "we chose you because of integration X."

Sales would claim deals required integrations. But when we asked customers post-sale, integrations weren't in their top 5 reasons for buying.

The integrations helped reduce objections ("yes, we integrate with your stack"). But they didn't drive decisions. The ROI was approximately zero for 35 of 47 integrations.

The Hidden Cost:

Beyond dollars: engineering morale.

Nobody wants to maintain 47 integrations. It's not interesting work. It's not resume-building. It's thankless debugging of third-party API changes.

Our best engineers avoided integration work. Junior engineers got stuck with it. Turnover on integration-heavy teams was higher.

Section 4: Our Pruning Strategy

We made a dramatic decision: cut 70% of integrations.

Usage Analysis:

We pulled usage data. Real usage, not "has it configured," but "actively using in last 90 days."

• 15 integrations had 50+ active users. Keep.
• 12 integrations had 10-50 active users. Evaluate case-by-case.
• 20 integrations had fewer than 10 active users. Kill candidates.

Customer Communication:

For the integrations we planned to kill, we:

• Announced 90-day sunset period
• Emailed all active users directly
• Offered migration support and alternatives (Zapier, manual export)

The Outcome:

We killed 32 integrations. Customer complaints: 3. Churned customers: 0.

The "critical" integrations weren't critical. Customers adapted. Most didn't notice.

What We Did With the Savings:

The 2 FTEs previously maintaining integrations were reallocated to core product development.

Within 12 months, we shipped features that directly drove revenue. Revenue up 20%. The ROI on killing integrations was enormous.

The New Philosophy:

We now have a high bar for new integrations:

• Must have a clear, recurring use case (not "nice to have")
• Must have 100+ customers actively requesting (not sales guessing)
• Must have a committed owner for ongoing maintenance

We've added 3 integrations in the last 2 years. All three are heavily used. Quality over quantity.

Conclusion

Integrations look like a competitive advantage. "50+ integrations!" sounds impressive on a landing page.

But integrations that aren't used aren't advantages. They're liabilities. Each one is a maintenance burden, a support cost, a surface area for bugs.

Build integrations your customers actually use. Kill the rest. Reallocate engineering to what matters.

Integrations that aren't used aren't integrations. They're liabilities.