120+ Connectors and Counting: How We Turned the Integration Tax Into a Feature

The Integration Graveyard

The average B2B SaaS company spends 30-40% of engineering cycles on integrations, according to a 2024 Merge.dev survey. That's not building product. That's plumbing.

At Qonto, we called this the integration tax. Each connector required a dedicated engineer, custom error handling, bespoke auth flows, and ongoing maintenance that nobody budgeted for. After three years, we had 23 connectors. Enterprise prospects wanted 60+. The math didn't work.

You're staring at a Jira ticket titled "Add Xero sync." It's been estimated at six weeks. Six weeks for a single connector. One API, one data model, one set of edge cases you'll spend three sprints discovering.

What the Integration Tax Actually Costs

The obvious cost is engineering time. But the real damage is subtler.

Every hand-coded connector introduces a unique failure surface. When Salesforce changes a field type or HubSpot deprecates an endpoint, a connector built eighteen months ago by an engineer who's since left becomes a liability. You either fix it fast or watch data silently break.

Then there's the opportunity cost. Every sprint spent on connector maintenance is a sprint not spent on features that differentiate your product. The integration backlog grows faster than you can clear it, and each unbuilt connector is a customer you can't win.

How the MCP Connector Hub Changes the Equation

Well's MCP Connector Hub treats connectors as a first-class orchestration problem rather than a collection of one-off implementations. The shift changes who can build connectors, how fast they ship, and how reliably they run.

The architecture is straightforward. Instead of writing custom code for each integration, the Hub provides a unified protocol layer between your product and every external service. Each connector is a configuration against that protocol, not a standalone codebase.

This eliminates the N×M problem. Without the Hub, connecting N features to M services requires up to N×M integration paths. With a shared protocol, it's N+M. At 120+ connectors and growing, that difference is measured in years of engineering time.

The Hub also handles the unglamorous work that kills connector reliability: rate limiting, retry logic, auth token refresh, schema validation, and error normalization. Every connector inherits these capabilities for free.

The Dynamic Connector Registry: From Months to Minutes

The real unlock isn't the Hub. It's what feeds it. The Dynamic Connector Registry (DCR) auto-generates MCP-compatible wrappers from existing API specifications.

You point the DCR at an OpenAPI spec, a GraphQL schema, or a well-documented REST API. The registry analyzes the endpoints, maps data types to MCP's type system, generates the wrapper, and publishes a testable connector.

This isn't magic. It's pattern recognition applied to API design. Most APIs follow predictable conventions: CRUD operations, pagination, webhook patterns, OAuth flows. The DCR encodes these patterns and applies them to new specs.

When a pattern fits cleanly, the connector is fully automated. When it doesn't, the system flags the gaps and generates a partial wrapper that an engineer can complete in hours rather than weeks. The 80/20 rule applies: 80% of connectors are fully automated, 20% need human finishing.

We've used this approach to go from 23 connectors to 120+ in under a year. The pace is accelerating because each new connector teaches the registry more patterns.

What Happens After the Sync

Connecting data is only half the problem. Making sense of what just arrived is the other half.

Every connector in the Hub supports post-sync auto-summaries. When data flows in from a new source, the system generates a natural-language summary of what changed, what's new, and what needs attention.

Raw sync data is noisy. A hundred updated records might contain two that actually matter. The auto-summary layer applies context-aware filtering to surface signal from noise. It's the difference between "sync complete, 147 records updated" and "3 invoices overdue, 1 new vendor added, revenue up 4% vs. last sync."

For end users, this means they stop checking dashboards to see if their sync worked. The system tells them what happened and what to do next.

Connectors with auto-summaries have 2.8x the engagement rate of those without. The data pipeline becomes intelligence, not infrastructure.

Before and After: The Numbers

Time to ship a new connector: before, 4-8 weeks of engineering time. After, 15 minutes for standard APIs, 2-3 days for complex ones.

Maintenance burden: before, each connector required roughly 4 hours per month. With 23 connectors, that's 92 hours, more than half an engineer's monthly capacity. After, the Hub centralizes maintenance. One fix applies everywhere.

Failure rate: before, connector failures averaged 3.2 per week across the fleet. After, centralized error handling and automatic retries reduced failures to 0.4 per week. An 87% reduction.

Coverage: before, 23 connectors after three years. After, 120+ connectors in under twelve months, with a clear path to 150+ by year-end.

Engineering allocation: before, 35% of backend engineering time went to integration work. After, 8%. The freed capacity went directly into product features that drive retention.

How to Think About Your Own Integration Strategy

If you're building a product that connects to external services, here's what we learned.

Start with the protocol, not the connector. The biggest mistake we made at Qonto was treating each integration as a standalone project. Define your internal interface first. Make it opinionated. Every connector should be a configuration against that interface, not a custom codebase.

Invest in auto-generation early. The DCR paid for itself after the seventh connector. Before that, it felt like over-engineering. After that, every new connector was nearly free.

Don't skip post-sync intelligence. Raw data piped into your system creates noise. Summarization and filtering are what make the difference between a connector that gets used and one that gets ignored.

Measure maintenance, not just delivery. Shipping a connector is a one-time cost. Maintaining it is recurring. If you're not tracking hours spent on connector upkeep, you're underestimating your integration spend by at least 3x.

Treat connector count as a product feature. Your customers evaluate you partly on what you connect to. A hundred connectors that work reliably is a stronger moat than ten hand-polished ones.

Integration as Growth Engine

We built Well's connector infrastructure because we'd lived the alternative. Months of engineering time burned on plumbing. Customers churning because you didn't support their CRM. A backlog that grew faster than the team.

A hundred and twenty connectors later, integration isn't a cost center. It's a growth engine. Every new connector makes the product stickier, the data richer, and the switching cost higher.

From an investor perspective, connector count is one of the clearest moat indicators in horizontal SaaS. It creates data gravity: the more sources flowing into your platform, the more valuable the aggregate becomes, and the harder it gets for a competitor to replicate.

The integration tax is real. But it's not inevitable. The teams that turn it into a feature will have a structural advantage that compounds with every connector they add.

If you're spending more than 15% of your engineering time on integrations, something is broken. We'd like to show you what fixed looks like.