How to Connect All Your Business Tools Without an Integration Team

The average mid-market company uses 130+ SaaS tools. Someone on the team, usually in finance or ops, is the unofficial glue between all of them. They copy deal data from the CRM into accounting software. They reconcile bank feeds against invoices by hand. They update shared spreadsheets from multiple sources, hoping nothing falls through.

That person spends 20+ hours a month on it. A quarter of their working time acting as a human API.

I know this because I helped build the other side of the problem. At Qonto, we shipped over 15,000 integrations in three years, each one hand-coded by engineers. Watching that process taught me that the model was fundamentally broken.

Building integrations the hard way

Here's how integration typically works. Your company decides to connect Salesforce to QuickBooks. An engineer scopes the Salesforce API, then the QuickBooks API. They map data fields between two completely different schemas. They write authentication logic, error handling, retry mechanisms, rate limiting. They test edge cases for weeks.

Six weeks later, you have one integration. It works until Salesforce changes their API, or QuickBooks deprecates a field, or your accounting team restructures the chart of accounts. Then the engineer goes back in, debugs, patches, tests again.

At Qonto, this cycle repeated thousands of times. Some connectors became full-time jobs for individual engineers who were the only people who understood the code. Every sprint spent babysitting a webhook handler was a sprint not building the product.

The painful irony: every integration followed the same pattern. Authenticate, read data, transform, write. The logic was identical across nearly all of them. Only the API shapes differed. We kept solving the same problem because no standard existed to describe what a tool could do and let software handle the rest.

iPaaS platforms like Zapier and Make moved this work from code to visual builders. That helped for simple cases. But a company with 200 Zaps has 200 independent data pipelines, each with its own failure mode and its own version of the truth. The person who built a given Zap often left months ago. The documentation is the Zap itself.

These tools also don't understand the data they move. A Zap copying a field from HubSpot to QuickBooks can't flag that the currency code is wrong or the contact doesn't exist in the target system. It's plumbing, not intelligence.

What changes with MCP connectors

Model Context Protocol (MCP) is an open standard for how AI systems interact with external software. The useful analogy is USB: before USB, every device needed its own cable and driver. After USB, one interface handled most devices. MCP aims to do the same for software integrations.

At Well, we built a Dynamic Connector Registry that reads existing API specifications and generates MCP-compatible connectors automatically. This is how we went from 0 to 120+ connectors without dedicated integration engineers.

A note on what "without an integration team" means in practice. We didn't hire people whose sole job was building connectors one by one. Engineers built the registry system that generates connectors. The work shifted from building individual integrations to building the machine that builds integrations. That's a meaningful difference, but it's not the same as saying no engineering was involved.

Connecting a tool looks like this:

1. Pick your tool from the catalog.
2. Paste your API key or click through an OAuth flow.
3. You're connected. No configuration screens. No field mapping. No workflow builder. Under two minutes for most tools.

The deeper change is what happens after connection. Traditional integrations move data from point A to point B. MCP connectors let the AI reason about the data it's moving. When you ask "create an invoice for the Acme deal," the AI pulls the deal amount from your CRM, looks up the billing contact, checks payment terms, and creates the invoice in your accounting software. It can flag that the deal currency doesn't match your invoicing default or that the billing address is incomplete.

The difference: a traditional integration wouldn't catch those mismatches. A human would, eventually, after spending an hour reconciling. The AI catches them at the moment of action.

Why connector count compounds

Integration platforms have always been valued partly on connector count. But building connectors by hand creates a linear scaling problem: twice the connectors means roughly twice the engineering cost. Even well-funded iPaaS companies plateau.

Generating connectors from API specifications changes that curve. The marginal cost of connector 121 is close to the cost of connector 12. The bottleneck shifts from engineering capacity to API documentation quality on the provider's side.

This matters for two reasons.

First, it enables coverage of the long tail. The 120+ connectors available today cover the core mid-market stack: CRM, accounting, banking, payments, communication, project management, HR. But every company has one or two niche tools that no integration platform supports because the market for each connector is too small. Automatic generation makes those connectors economically viable for the first time.

Second, each connector added increases the value of every existing one. This is a genuine network effect, not a marketing claim. When a user connects their banking tool to a system that already has their CRM and accounting data, entirely new queries become possible. Reconciling across three systems by asking a question instead of exporting CSVs. Spotting a payment discrepancy that lives in the gap between two tools. The value isn't in any single connector. It's in the density of connections.

From an infrastructure perspective, the Dynamic Connector Registry signals something specific: the integration layer is programmatic, not artisanal. Companies that hand-build connectors carry linear engineering debt. A registry-based approach treats connectors as generated artifacts, which means the system improves at the platform level rather than connector by connector. When MCP evolves or an API standard changes, fixes propagate across the entire connector base automatically.

The target of 500+ connectors isn't just a growth metric. It's the threshold where the platform becomes the default way to connect business tools, because whatever tool you need is already there.

What this doesn't solve

The title says "without an integration team." Here's where that claim holds and where it doesn't.

It holds for standard SaaS tools with documented APIs. If your tool is in the catalog or has a well-documented REST API, you connect it yourself with an API key. No engineers needed for the connection.

It doesn't hold for everything. Real-time event streaming, high-volume data pipelines, systems with proprietary protocols, legacy software with no API. These still require custom engineering. The honest estimate: around 80% of typical mid-market integration work can be handled through auto-generated connectors. The remaining 20% still needs engineers.

Data quality remains your problem. Duplicate CRM contacts and messy chart of accounts categories don't fix themselves when you connect more tools. They propagate faster.

Permissions require deliberate setup. When an AI can read your CRM and write to your accounting system, the consequences of a mistake are real. Define access controls carefully: what the AI can read, what it can write, what actions need human approval.

Complex business logic needs human input. Standard invoice creation works out of the box. Custom billing rules, revenue recognition requirements, multi-step approval workflows need to be defined by someone who understands the business. The connector handles plumbing. Your domain knowledge is still required for the logic.

AI reasoning has limits. The AI might misinterpret an ambiguous field name or make an incorrect assumption about how two datasets relate. For high-stakes operations, particularly financial transactions, human review of AI-initiated actions is prudent until you've built confidence in the system's accuracy with your specific data.

The practical impact

When your tools are connected and an AI understands the data flowing between them, the 20+ hours of monthly manual sync work shrinks dramatically. The finance person who spent every Monday morning reconciling systems can ask "show me discrepancies between CRM deals and outstanding invoices" and get an answer in seconds.

For mid-market companies evaluating whether to hire integration engineers or adopt an iPaaS platform, MCP-based connectors represent a third path. You don't need a team to build standard connections. You don't end up with a sprawl of trigger-action workflows nobody fully understands. And the AI layer means your integrations catch problems that dumb pipes never would.

The realistic expectation: connect your core tool stack in an afternoon, eliminate most manual data sync, and defer hiring integration specialists until you genuinely need custom work that auto-generated connectors can't handle.

That last point matters. You're not eliminating the need for integration engineering permanently. You're pushing it to the boundary where it actually belongs: the hard, custom, genuinely complex problems that justify engineering time. Everything else, the standard connections that eat 80% of integration budgets, becomes infrastructure you configure rather than build.

For the person who was spending five hours every Monday copying data between systems, the difference is immediate. For the company, the difference is structural: integration becomes a platform capability rather than a staffing problem.