Build vs buy integrations: when writing your own is the wrong call

Should I build or buy an integration?

Buy it if the integration is plumbing, and build it if the integration is the point. A Stripe to QuickBooks sync makes no customer choose you. A pricing engine that reads live inventory out of your own warehouse system might. Everything else in the decision is a variation on that question, dressed up in a spreadsheet.

The reason teams get this wrong is that the build looks small from the outside. An engineer reads the API docs, sees a clean REST endpoint with JSON that maps almost one to one onto an internal model, and says two weeks. They are usually right about the two weeks. They are estimating the demo, not the system that has to run unattended at 3am on a holiday weekend while a rate limit tightens and a token expires.

What does a "simple" integration actually contain?

A production-grade connector is roughly a dozen concerns, and only one of them is "call the endpoint." Here is the honest inventory, and who carries each piece when you build versus when you buy. Anything in the "you" column is code you write, test, monitor, and keep alive for as long as the integration exists.

Component	If you build	If you buy
auth and token refresh	You implement OAuth, store secrets, refresh before expiry, and handle revoked grants	Vendor, including refresh and re-consent flows
pagination	You handle cursors, offsets, and the endpoint that silently caps at 100 records	Vendor
Rate limits and backoff	You implement exponential backoff, jitter, and a queue so one big backfill does not starve live syncs	Vendor
idempotency and dedupe	You design keys so a retried write does not create a second invoice	Vendor
Field mapping and type coercion	You write and maintain the mapping in code; every change is a deploy	You, but in a visual mapper, no deploy
Partial failure and retries	You decide what happens when 3 of 500 records fail, and make it resumable	Vendor, with per-record status
Backfill and replay	You build a separate historical loader, usually twice	Vendor
Dead-letter handling	You build a queue, a viewer, and a way to reprocess	Vendor
Observability and alerting	You emit metrics, define freshness SLOs, and wire the pager	Vendor for run health; you still own business alerting
Secret rotation	You, on a schedule, in every environment	Vendor
API version upgrades	You, on the upstream vendor's timeline, not yours	Vendor, usually before you notice
Business logic	You	You

Notice the last row. Buying does not outsource your business logic, and it should not. What it removes is the transport layer underneath it. That distinction is the whole argument, and it is easier to see once you understand what an API adapter does: it standardizes auth, paging, and error semantics so the only thing left to decide is which field goes where.

How long does it take to build an API integration?

A first working sync against a well-documented REST API takes a good engineer one to three weeks. Getting it production-grade, with retries, backfill, dead-letter handling, and alerting, typically takes two to three times that again. The number that matters is not the first ship date. It is the recurring cost after it.

Two things reliably blow up the estimate. The first is a source system whose data model does not match yours: custom objects, picklists that reject unknown values, currencies in minor units, timestamps in a timezone nobody documented. The second is freshness. If the business wants near real time, you now have a webhook receiver to run, with signature verification, replay protection, and a polling fallback for when the upstream drops events. The tradeoffs are laid out in webhooks vs polling, and both sides of it are work you now own.

How much does it cost to maintain an integration?

Plan on a meaningful slice of one engineer per connector per year, and more if the upstream API moves fast. Maintenance is not idle time. It is version deprecations, schema changes, new required fields, tightened rate limits, expired credentials, and the pager going off when a source system has an outage you did not cause.

The honest way to model it: an in-house integration is a subscription. You just pay it in salary instead of invoice, and the price goes up as you add systems. Loaded cost for a US mid-market engineer is well north of $150k, so even a modest fraction of one person's year, spent on connector upkeep, dwarfs a flat data integration pricing plan. The difference is that the salary line never shows up on the integration's budget, which is exactly why build looks cheap.

What is the hidden cost of in-house integrations?

The hidden cost is drag: every connector you own is a permanent claim on your roadmap. Upstream APIs deprecate versions, change schemas, and add required fields on their schedule, not yours. Each of those events preempts whatever your team was actually hired to build, and the interruption arrives without warning.

There is a second, quieter cost. Integrations built one at a time tend to become a mesh of bespoke scripts, each with its own retry logic and its own idea of what a customer record looks like. Six systems wired directly to each other is fifteen possible connections, and the failure modes compound in the ways described in point to point integration problems. Nobody plans that architecture. It accretes, one "quick" script at a time.

And monitoring is rarely in the original estimate at all. A pipeline that runs is not the same as a pipeline that is correct: someone still has to watch freshness, volume, and schema drift after the thing is live, because the failure that hurts is not the job that crashes loudly at 2am. It is the job that succeeds every night while quietly syncing zero rows, and nobody notices until finance closes the month.

When does building a custom integration make sense?

Building is right when the integration is genuinely yours to own. That means one of five things is true: the system is proprietary, the logic is your moat, the latency or residency constraints are extreme, the volume makes per-unit vendor pricing absurd, or a security rule forbids a third party from touching the data at all.

• No usable API surface. An internal ERP, a mainframe, a machine controller writing to a flat file on a share. If there is nothing standard to connect to, a vendor connector cannot exist, and you are writing the adapter regardless.
• The integration is the product. If customers pick you because of how your sync behaves, that logic belongs in your codebase. A revenue-recognition engine that reads live billing data is not plumbing. It is the thing you sell.
• Hard latency or residency requirements. Single-digit millisecond paths, or a rule that says the data physically cannot leave a VPC or a jurisdiction. Read the vendor's deployment options carefully before you conclude this, but when it is real, it is decisive.
• Volume economics flip. At billions of rows on one predictable path, a purpose-built pipeline can be cheaper than metered pricing. Note that this is an argument against per-task billing specifically, not against buying, which is why flat pricing exists.
• The security constraint is absolute. Some regulated environments cannot grant a third party credentials, full stop. That ends the debate, and the maintenance cost becomes a compliance cost you accept.

What is not on that list: "our data model is unusual," "we want full control," and "our engineers can do it in a sprint." All three are true of nearly every company, and none of them are worth a decade of upkeep on a Salesforce connector.

How do I decide? A five-signal scorecard

Score the integration on five signals before anyone opens an editor. If most rows land in the right column, buy it, and spend the engineering time on something a customer will pay for.

Signal	Build if	Buy if
Differentiation	Customers choose you partly because of this integration's behavior	It is table stakes; nobody buys because of it, but they would churn without it
Number of systems	One or two, and the set is stable	Three or more, and ops keeps asking for the next one
Upstream change rate	Internal system you control, schema changes when you say so	Public SaaS API with versioned deprecations you do not control
On-call coverage	You already run a real 24/7 rotation that can take pipeline pages	Your "on-call" is whichever engineer sees the Slack message first
Time to first value	Months are acceptable and the roadmap has room	Somebody needed this last quarter

In-house integration versus an iPaaS is not a purity contest. Most teams end up doing both: they buy the connectors for standard SaaS systems, and they build the two or three pieces that encode something only they know. The mistake is the reverse split, where a small team hand-builds nine commodity connectors and then has no capacity left for the one that would have been worth building.

Should customer-facing integrations be built or bought?

If you sell software, the integrations your customers see are part of your product, and the standard changes. They need per-tenant credentials, per-customer error visibility, and support engineers who can explain why a sync failed. That is a product surface, not a script, and the maintenance burden multiplies by the number of customers, not the number of connectors.

The pragmatic answer is to own the parts customers touch (the connect flow, the mapping UI, the error messages) and buy the transport underneath. An API integration platform that exposes auth, mapping, and run logs through an API lets you keep the experience while somebody else absorbs the next OAuth scope change from a vendor you have never met.

Whatever you decide, decide it with the real numbers. Add up the components in the first table, multiply by the number of systems, then multiply again by the years the integration will exist. If that total is bigger than a data integration platform subscription, and for commodity connectors it almost always is, the build was never the cheap option. It just billed you slowly. The fastest way to check the math is to map your own pair in the live demo and see how much of that table you would never have to write.