When to Build a Custom Integration vs Use a Connector

The build-vs-connector decision usually gets made in about twenty minutes during a kickoff call. Someone finds a connector, it looks like it covers the use case, and the team moves on to the next fire. The actual cost of that call doesn't show up until three or six months later, when the connector's assumptions collide with how the business actually operates, and someone's maintaining a growing list of exceptions in a Notion doc nobody else knows exists.

One analysis of a common Slack-ServiceNow pattern lays this out well: an engineer builds the connector, it works, everyone moves on. Six months later the vendor changes its API versioning, the Slack workspace gets reorganized, and the person who built the thing has moved teams. It still runs. Mostly. But nobody's confident about the error handling anymore, and that's the moment the "quick" decision starts collecting interest.

The scale of the underlying problem is bigger than any one integration. Salesforce's 2026 Connectivity Benchmark, an annual survey now in its eleventh year, polled 1,050 IT leaders in October and November 2025 with research firm Vanson Bourne and input from Deloitte Digital. It found the average organization runs 957 applications, and only 27% of them are actually connected. That gap is exactly why teams reach for the fastest available connector: there's simply too much surface area to build everything custom. It's also exactly why so many of those fast choices calcify into expensive, brittle ones nobody wants to touch.

The fix isn't picking a side between "build" and "buy." It's knowing which conditions predict that a connector holds up, which conditions guarantee it won't, and asking the right questions before the decision gets made for you by an outage.

The three paths practitioners actually choose between, not two

Most advice on this topic frames it as a coin flip: build it yourself or buy a connector off the shelf. Anyone who's actually shipped integrations knows there are at least three real options, and most enterprise setups end up running all three at once, in different corners of the stack.

Pre-built connectors and native integrations are the fast lane. Think of the HubSpot App Marketplace: standard field mappings, maintained by the vendor, deployable without a custom development cycle. When the upstream API changes, the expectation is that the connector vendor handles the update on their side, reducing the burden on your team.

iPaaS (Integration Platform as a Service) is one level up in scope. It's managed infrastructure that hosts many connectors, not a single connector. It trades some flexibility for speed and lower maintenance across standard systems. The category held 33.10% of the enterprise application integration market in 2025, and cloud-native iPaaS is projected to grow at a 24.95% compound annual rate through 2031, according to Mordor Intelligence. That's not a niche approach. That's most of the market voting with its budget.

Custom API integration is the purpose-built option: governed code around your actual schemas, your auth flow, your retry logic, your error handling. Nobody's forcing your workflow into someone else's generic template here. You're building the thing to match the payload shape and validation rules you already have, not the ones a vendor assumed you'd have.

Worth naming a fourth option too, since most vendor guides skip it: vendor-managed "hybrid middle" platforms, like certain Azure-based approaches, that blend iPaaS convenience with custom-level control. It exists specifically because the three-path model isn't exhaustive, and pretending otherwise sets readers up to miss a legitimate option.

The practical default across most organizations: iPaaS handles the routine flows, custom integration gets reserved for the handful of cases that genuinely demand it. Hybrid is the norm. Nobody serious runs a pure-build or pure-buy shop.

The conditions that reliably predict a connector will hold

Here's the core test, stripped down: does the data flow match a standard business process, and does the connector support the fields you need without modification? If yes to both, a connector probably holds.

The signals line up pretty cleanly:

Both endpoints need supported connectors, full stop. A platform's whole value proposition depends on that being true at both ends of the sync, not just one. The workflow itself should be standard too. Syncing contacts and deals between Salesforce and HubSpot, or order data between NetSuite and a common e-commerce platform, is well-trodden ground. Thousands of companies have already hit the edge cases and the vendor's already patched them.

Speed matters more than customization depth here, and the team usually lacks dedicated integration engineers, so leaning on the provider's support queue is a feature, not a compromise. Budget is tight, and, crucially, the use case genuinely fits inside what the connector was designed for rather than stretching it.

This fits small and mid-size companies especially well: fast-growing businesses that need connectivity now and can't absorb a custom build's price tag, startups running lean. The maintenance promise is real, too. The provider handles API version changes, so the integration keeps pace as connected apps evolve, without anyone internally tracking vendor changelogs.

The failure mode hides in plain sight, though. Connector setup assumes a solid prebuilt connector actually exists for your exact case. When it doesn't, the "quick" option quietly turns into a custom project running inside someone else's platform, minus the visibility a real custom build would have had. You end up with bespoke logic, but none of the ownership clarity.

There's a secondary risk worth naming: you're now riding the provider's roadmap, their pricing changes, their uptime. A change on their end can break your integration with zero warning, and there's no one on your side who saw it coming.

One clean gut-check, courtesy of engaging.io's analysis: if describing the required behavior takes more than two "and then, unless" clauses, the use case has already wandered out of connector territory. That's not a maybe. That's a signpost.

The five conditions that predict a custom build is the only path that holds

These aren't preferences, and they're not edge cases you can wish away with a workaround. Each one is a structural condition where connector architecture breaks by design, not by accident.

Trigger 1: Internal or proprietary systems with no connector. A connector's value depends on both endpoints having one built. If one side is an in-house CRM, a homegrown product database, or any tool your team built from scratch, no vendor connector exists to plug into it, because the vendor has never heard of your system. Syncing a service desk with a proprietary internal database means code gets written no matter what. The only real question is whether that code is governed and documented, or duct-taped together at 11pm before a demo.

Trigger 2: Complex multi-system orchestration. Coordinating updates across three or more systems with conditional logic routinely exceeds what a visual flow builder can express. Once the integration needs to apply different business rules depending on state across multiple systems, platform limits stop being an inconvenience and start being an actual wall. One roofing company, documented by aptitude8, needed three separate material suppliers folded into a unified ordering platform inside HubSpot, each with its own pricing logic and its own product naming conventions. No native connector could handle that combination of pricing logic and naming conventions. It had to be built.

Trigger 3: Compliance and regulated data handling. Some regulated environments require the transformation logic itself to be auditable at the code level, or need the integration to stay inside specific network boundaries. Custom integration allows a direct, encrypted path with a minimal data footprint, auditable at every hop. Worth flagging: DORA, the EU's Digital Operational Resilience Act, entered into application in January 2025 and applies to financial-sector entities, imposing real ICT risk management and third-party risk requirements on SaaS and cloud vendors. A connector that routes regulated data through a third-party iPaaS may simply not satisfy those third-party risk rules, no matter how convenient it is.

Trigger 4: When integration is the product, not a workflow behind it. For B2B SaaS companies selling connectivity as a feature, a generic connector can't represent the product's own data model or enforce its own business rules; it wasn't built to. Context matters here: the average API grew from 22 endpoints in 2023 to 42 in 2024, and 82% of organizations report having adopted some level of API-first strategy. Yet only 2% have connected more than half their applications. That gap between ambition and what's actually wired together is exactly where custom integration earns its keep. It shows up at every growth stage in B2B SaaS, not just once a company hits enterprise scale.

Trigger 5: Legacy and non-REST systems. Mainframes, proprietary protocols, systems that predate the concept of a modern API. iPaaS connectors almost universally assume HTTP or REST or some other standard protocol. Connecting to a system that doesn't speak that language requires custom code no matter what, and the only variable is whether that code is documented and owned or quietly maintained by whoever wrote it last.

Worth adding a sixth signal, also from aptitude8: custom objects. One membership organization ran a HubSpot instance with six custom objects and numerous custom properties layered across them. Most integrations against a structure like that require custom API development just to keep data consistent, because no native connector understands relationships that specific. It was never designed to.

Why the maintenance burden is invisible until it isn't

Return to the earlier pattern. The build takes a few days. It works. Months pass, a vendor changes its API versioning, the workspace gets reorganized, and the engineer who wrote the original integration has since moved on. The integration still runs, mostly, but nobody's fully sure how the error handling behaves anymore.

That's not a horror story. That's a common outcome.

Here's what accumulates without anyone tracking it as a line item. Every API change that breaks the integration costs someone a few hours to diagnose, and that cost gets spread across different people in small chunks, never once logged as "integration maintenance." Knowledge fragments too: each custom integration creates its own little pocket of specialized understanding. When that pocket lives in one person's head, there's a single point of failure. When it's spread across a few people instead, nobody actually holds the full picture, which is arguably worse.

The integration turns into a black box that demands archaeological work every time something needs to change. New hires ask how it works. Nobody remembers exactly. The README, if one ever existed, is out of date. The same explanation gets typed into the same Slack thread for the third time this year, by a different person, slightly wrong each time.

The infrastructure underneath compounds it further. Every custom integration needs error handling that actually surfaces what broke, logging detailed enough to debug from, authentication that isn't just an API key pasted into a shared doc somewhere, and monitoring that flags a failure before a customer does. Someone builds all of that once. The next team, on the next integration, often rebuilds it from scratch, because nobody wrote down that it already existed.

engaging.io frames the real test simply: if the person who built the integration leaves, and the honest answer is "we'd be stuck," that's a maintenance model problem, not a technology problem. The fix isn't a better framework. It's ownership assigned in advance, in writing, before the thing ships.

That's the asymmetry worth sitting with. A connector's ongoing cost tends to surface as a recurring fee. A custom build's ongoing cost is engineering time that nobody counts, because it never shows up as a single number anywhere.

Total cost of ownership: why the cheapest integration to build is often the most expensive to own

The build cost is the part everyone sees. It's the number in the proposal, the line in the budget, the thing that gets approved in a meeting. The maintenance, monitoring, incident response, and the cost of reshaping the integration estate as the company grows: all of that lands quietly on payroll and margin, and most organizations never actually total it up.

One industry analysis puts a number on this: for most business use cases, initial development is only 30 to 40% of the total cost of ownership. The majority of the spend happens later, in maintenance and updates, spread out over years instead of concentrated in a single invoice.

The cost difference becomes concrete when you account for maintenance over time. Annual upkeep adds a meaningful chunk of the original build cost every year, compounding across a portfolio of integrations. The gap between a multi-year custom TCO and an equivalent iPaaS spend can be substantial — and it widens with each integration added to the estate.

That gap is not a rounding error.

It's worth naming the counterexample, too, because the framework should cut both ways. One aptitude8 client avoided a genuinely complex custom integration entirely, through architecture planning that used a reverse ETL approach instead, saving real money and shipping faster than the custom path would have allowed. Sometimes the smartest build decision is realizing you don't need to build anything.

And connectors carry their own hidden cost, just pointed the other direction. When a connector doesn't quite fit and the team ends up patching the gap with manual workarounds every week, that cost is invisible too. It shows up as ops time, buried in someone's calendar, never as a line item on the integration budget. Nobody adds it up until the person doing the manual patching quits.

The practical fix: run the TCO analysis before either path gets approved, not after the build is already underway and sunk cost has started whispering in everyone's ear. And that analysis has to include the maintenance estimate, not just the build quote. A build quote without a maintenance line is half a budget.

A three-question framework for making the call before it makes itself

Three questions, confirmed across multiple sources as the axes that actually predict which path holds.

How standard is the data flow? Standard means syncing contacts, deals, or common objects between widely-used platforms, and that's connector territory, plain and simple. Non-standard means conditional routing, multi-system state, custom objects, or proprietary payloads, and that's custom territory. Run the "and then, unless" test here: more than two conditional clauses to describe the required behavior means the use case has already left connector territory behind.

How complex is the logic behind the sync? A connector moves data from point A to point B. It cannot decide what happens to that data once three different systems and a stack of business rules get involved, because that's not what it was built to do. Custom objects, multi-system routing, compliance-driven transformation rules: all of it pushes toward custom. And if no native connector on the market can understand or maintain the data relationships the business has already built (like that six-custom-object HubSpot instance), the architecture has already answered the question for you.

Who maintains it when it breaks, and what happens if they leave? With a pre-built connector, the vendor maintains it and absorbs the API changes; the maintenance cost is the subscription, full stop. With a custom build, whoever built it maintains it, which means ownership, documentation, and a runbook need to be assigned before the build starts, not scrambled together after it breaks. If the honest answer to "what happens if the builder leaves" is "we'd be stuck," that's a maintenance model problem masquerading as a technical one.

Run those five custom-build triggers back through the three questions and the pattern holds together cleanly. Proprietary systems get answered by question one: no connector exists, end of discussion. Complex orchestration gets answered by question two: the logic exceeds what a visual flow designer can express. Compliance needs questions two and three together, since auditability demands both code-level control and a named owner. Integration-as-product draws on one and two at once, because the data model is the product, and a generic template simply can't represent it. Legacy and non-REST systems get answered by question one again: no standard protocol connector applies, because the system predates the whole idea of one.

Most enterprise implementations end up blending all three paths anyway, iPaaS for the routine majority, custom for the handful of cases these five triggers actually flag, connectors wherever a vendor's already solved the exact problem. The decision was never really build versus buy. It was always about matching the tool to the specific shape of the problem, and asking the maintenance question before the build starts instead of six months after, when the person who could've answered it has already left for a different job.