Build vs Buy for SaaS Integrations: A Real Cost Framework

TL;DR

Choosing whether to build or buy customer-facing SaaS integrations is difficult because initial development estimates and vendor pricing capture only part of the long-term cost. To account for the full cost, this guide compares the two options across API complexity, engineering time, maintenance, and opportunity cost, and then provides editable calculations and a scoring table to apply the framework to an integration roadmap.

When teams include maintenance and opportunity cost in the calculation, building makes sense if the connector is part of the product’s core value or the roadmap includes only one integration, while buying becomes more economical once several connectors begin competing with core product work. For a multi-connector roadmap, Ampersand pairs open-source, extendable connector code with managed authentication, sync, and monitoring across customer accounts, so product teams can shape each connector and reduce the engineering time required to operate multiple integrations in production.

When SaaS Teams Face the Build-or-Buy Decision

Building the first customer-facing integration often feels manageable because the team focuses on a single API and a single use case. As more connectors are added to the roadmap, each provider adds its own authentication rules, data models, rate limits, and failure modes, while every live connector continues to require support and maintenance.

Most teams have the skills to build another connector, but each new build adds a system the team must operate for years. The decision comes down to whether integration work is central to the product or keeps engineers from building core product features. Planned connector volume, API complexity, and expected maintenance provide a clear basis for deciding when to keep building and when to use integration infrastructure.

Estimated Connector Build Cost by API Complexity

API complexity can double or triple the time required to build a production-ready connector. The estimates below use a fully loaded engineering cost of $200,000 per year, or about $16,700 per engineer-month. Each range covers authentication, data sync, error handling, and a basic customer-facing setup screen. It assumes that the engineers have built production API integrations before but have not worked with the specific provider.

A provider can move between tiers as the integration scope changes. Reading a few standard objects requires less work than supporting custom fields, bidirectional sync, historical backfills, and webhook subscriptions across many customer accounts.

Teams building their first connector should plan near the top of the relevant range because they must also create shared systems for token storage, retries, sync scheduling, and customer configuration. Under these assumptions, building HubSpot, Salesforce, and NetSuite connectors would cost about $150,000 to $225,000+ before maintenance begins. The complete cost calculation must also include the engineering work that follows launch.

Why Maintenance Can Cost More Than the Initial Build

The build estimates above end when a connector reaches production. From that point, the team must keep every customer connection authenticated, maintain reliable data delivery, and adapt the connector as customer accounts and provider APIs change. For planning purposes, the 30/70 cost model assigns 30% of lifetime engineering work to the initial build and 70% to maintenance. Ampersand’s analysis of why integration maintenance can consume 80% of engineering time explains how this workload grows as more customer installations go live. Both figures provide planning baselines that will vary with customer count, API complexity, and provider stability.

Authentication and token refresh: Each customer connects with separate credentials, which can fail when a token expires, an administrator revokes access, or the provider changes its authorization requirements. The team must detect the failure, guide the customer through reconnection, and confirm that data delivery resumes.

Webhook delivery and rate limits: Reliable sync requires retries, deduplication, and reconciliation because webhook events can arrive late, out of order, or more than once. Rate limits may also vary by endpoint, customer account, and provider plan, so each installation needs its own throughput controls.

Schema changes and debugging: Administrators can rename fields, add validation rules, or modify objects after setup. When a customer’s sync breaks, engineers must isolate the affected installation and determine whether the connector, the customer configuration, or the provider caused the failure.

Under the 30/70 model, an $80,000 build implies about $187,000 in maintenance across three years, or roughly $62,000 per year. The connector’s total engineering cost would therefore reach about $267,000, with maintenance costs more than twice the initial build cost.

Opportunity Cost and the Breakeven Point

A build estimate and an annual platform fee cannot be compared directly because they cover different periods and different work. For the in-house option, divide the initial build cost by 30% to estimate lifetime engineering cost. For the buy option, combine product implementation, platform fees, usage charges, and the internal maintenance that remains across the same three-year period. The decision must also account for the product work delayed while engineers build integrations.

Three-connector in-house cost: Building one connector from each API tier requires an estimated 7 to 10.5+ engineer-months. Based on the tier ranges above, the initial cost would fall between $117,000 and $175,000+. Under the 30/70 model, the three-year engineering cost would reach approximately $390,000 to $583,000+, or $130,000 to $194,000+ per year.

Opportunity cost: The initial estimate already includes the engineers’ salaries. Opportunity cost represents the product work delayed during those 7 to 10.5+ engineer-months. Integration work incurs higher business costs when it delays features tied to customer acquisition, retention, or revenue.

Three-connector buy cost: The buy-side calculation follows Ampersand’s usage-based pricing, which scales with the volume of data delivered. The Launch tier is free for up to five production customers, while Catalyst costs $999 per month and supports up to 25 production customers with 2 GB of monthly data delivery.

If connecting Ampersand to the product requires 20% to 30% of the original in-house build effort, implementation would cost about $23,000 to $53,000+. Three years of Catalyst would add about $36,000, bringing the estimated total to $59,000 to $89,000+ before excess data charges, higher-tier pricing, and maintenance of product-specific logic.

Where breakeven occurs: Under the stated assumptions, buying is less expensive for the three-connector roadmap. A single connector still requires strategic judgment because in-house ownership can make sense when the integration defines the product. Once the roadmap contains several standard integrations, each in-house connector adds development and maintenance work, while managed authentication, scheduling, and monitoring support the full catalog.

At an average of 2.5 engineer-months per connector, building 40 connectors would consume 100 engineer-months, or more than eight engineer-years, before maintenance begins. At that scale, the company is funding a permanent integration infrastructure program alongside its core product.

When Building Integrations In-House Makes Sense

Building in-house is justified when ownership creates product value or satisfies a requirement that external infrastructure cannot meet. Three situations support that decision.

One stable connector: Building can make sense when the roadmap includes a single connector with a limited scope and no second integration requests from sales or customers. A single narrow connector keeps the technical surface small and avoids adopting a platform whose shared infrastructure would support only one connector. Confirm the assumption against the committed roadmap and recent customer requests.

The integration defines the product: Keep the connector in-house when its depth directly influences why customers choose the product. A revenue intelligence tool that competes through detailed Salesforce support may need complete control over provider-specific data, sync behavior, and API capabilities. In this case, the integration represents core product development rather than supporting infrastructure.

No external provider can meet the deployment requirements: in-house development may be necessary for air-gapped environments, strict data residency policies, or regulated deployments with mandatory architectural requirements. The build requirement applies only when no available service, including providers that offer VPC or bring-your-own-cloud deployment, can pass the security review.

When Buying Integration Infrastructure Is the Right Call

Buying becomes more economical when integration requirements repeat across providers and customer accounts. The product team still owns how integrations work inside the application, while shared systems for authentication, data delivery, and diagnostics support the complete connector roadmap.

Several connectors on the roadmap: A second or third connector repeats authentication, retries, scheduling, and monitoring for another provider. Building integrations in-house becomes harder at scale because the team must maintain every live connector while continuing to build the next one.

Many customer accounts: Each customer connects a separate SaaS account with its own credentials, permissions, schema, and configuration. Managed infrastructure handles those connection lifecycles and isolates failures to the affected customer, reducing the amount of tenant-specific code the product team must operate.

Fresh data is a product requirement: Products that act on provider events need reliable webhook registration, retries, event ordering, and reconciliation. For AI automation products that depend on SaaS integrations, stale or missing data can delay the actions customers expect the product to perform.

A small engineering team has a crowded roadmap: Connector development competes with product work for the same engineers. Customer-facing configuration and installation-level diagnostics also allow support teams to resolve more connection issues without waiting for the engineers who built the connector.

Integrations support the product without defining it: Customers may require connectors to Salesforce, HubSpot, or other systems before adopting a product, even though they choose it for its workflow, automation, or insights. Owning the underlying integration infrastructure adds engineering work without strengthening the product's core value.

Buying still requires choosing the right type of integration platform. Unified APIs cover many providers through standardized schemas, while embedded iPaaS products let teams configure workflows visually. Products that need native API depth, custom objects and fields, and an extendable connector codebase should choose a native integration platform such as Ampersand.

The Middle Path: Build on Open Source, Buy the Infrastructure

Control over connector code is a valid reason to hesitate before buying integration infrastructure. With a closed connector layer, provider-specific authentication, pagination, and request logic remain proprietary, so the product team cannot inspect, extend, or reuse them independently. Ampersand separates this connector logic from the infrastructure required to run it across customer accounts.

An open connector layer: Ampersand Open Connectors is a public, MIT-licensed Go library that constructs API requests based on the required objects and fields. Engineers can inspect and extend the provider-specific logic, contribute changes, or use the library independently of Ampersand’s managed services.

Managed production infrastructure: When teams use the connector library with Ampersand, the managed service handles authentication flows, sync orchestration, provider quotas, retries, customer configuration, and diagnostics. The product team maintains control over what each integration does and how the connected data operates within the application.

A team that runs an open-source connector library independently keeps control of the code but must also build and operate the multi-tenant systems around it. A self-hosted native integration platform can provide those operational capabilities inside the company’s infrastructure. The comparison between self-hosted connector libraries and native product integrations explains where each approach places the operational responsibility.

Build vs. Buy Decision Framework for SaaS Integrations

Use the criteria below to evaluate the committed integration roadmap and current customer requirements. Security and deployment requirements should form part of the vendor review. Buying remains viable when a provider passes the review, while an in-house build becomes necessary when no available provider can meet a mandatory policy requirement.

Once security compatibility is confirmed, a clear majority across the remaining rows indicates which option better supports the current roadmap. A close result supports the middle path described above, where the product team keeps the connector logic that creates differentiation and uses Ampersand for the multi-tenant infrastructure shared across integrations.

Security requirements do not automatically force an in-house build. Ampersand is SOC 2 Type II and ISO 27001-certified, GDPR-compliant, and uses tenant isolation with encryption at rest and in transit. Teams can review the security specs in the Ampersand Trust Center and choose on-premises, VPC, or BYOC deployment on Enterprise when stricter infrastructure control is required.

FAQs: Build vs Buy for SaaS Integrations (2026)

How long does it take to build a Salesforce integration?

For a customer-facing SaaS integration that must work across different Salesforce organizations, plan for about 4 to 6+ engineer-months. Supporting custom objects and fields, API quotas, historical backfills, writes, and event subscriptions increases the timeline, while a narrow integration limited to standard objects may ship sooner. Customer pilots, security reviews, and production testing can further extend the calendar schedule.

How much does an integration cost to maintain per year?

Using the 30/70 lifetime cost model over three years, annual maintenance costs approximately $13,000 to $20,000 for a Tier 1 connector, $26,000 to $39,000 for a Tier 2 connector, and $52,000 to $78,000+ for a Tier 3 connector. Actual costs depend on the customer count, provider changes, and the number of installation-specific failures requiring engineering support.

Is open source a middle option between building and buying integrations?

Yes. Open-source connector code can give engineers control over provider-specific logic while managed infrastructure handles authentication, sync orchestration, retries, and customer-level monitoring. Ampersand follows this model through extendable Go connectors and a managed runtime. Ampersand’s guide to self-hosted connector libraries and native product integrations explains how each approach divides the operational responsibility.

When does build vs buy break even for SaaS integrations?

Breakeven occurs when platform implementation, fees, usage charges, and remaining internal maintenance match the three-year cost of an in-house build and its maintenance. One narrow connector may keep the costs close, while a multi-connector roadmap gives managed infrastructure more shared work to absorb. Teams can calculate the exact point by applying current Ampersand pricing and their own engineering estimates across the same period.

Do AI coding agents change the build-vs-buy math?

AI coding agents can reduce the time required to scaffold authentication, API clients, pagination, and tests. They do not refresh tokens, manage rate limits, adapt connectors to schema changes, retry failed deliveries, or debug customer-specific failures after launch, so their largest impact remains on the initial build. The analysis of agent-built CRM integrations explains why faster code generation has a smaller effect on lifetime integration cost.