Build vs. Buy: The True Cost of Building SaaS Integrations In-House

You just lost a six-figure enterprise deal because your app doesn't sync with Salesforce. The immediate reaction from engineering is predictable: "Give me a week. It's just a few REST API calls."

Fast forward six months. That single integration has spawned a dedicated sub-team. Your error logs are choked with 401 Unauthorized and 429 Too Many Requests errors. The platform you integrated with just deprecated their v2 API, forcing a complete rewrite. And the sales team? They just asked for 49 more integrations.

Build vs. buy for SaaS integrations is the strategic decision between dedicating internal engineering resources to write and maintain custom API connections (build) or purchasing a third-party Unified API to handle the infrastructure (buy).

In this post, we are breaking down the true costs of building integrations in-house, looking at the actual math, and providing an honest pros and cons comparison so you can make the right architectural decision for your team.

The "Just a Few API Calls" Trap

When product managers ask for an estimate to build an integration, developers usually look at the API documentation, find the endpoints they need, and estimate the time to write the HTTP requests.

This is the integration iceberg. The HTTP request is the 10% visible above the water. The remaining 90%—authentication, pagination, rate limiting, data normalization, webhooks, and ongoing maintenance—lurks below the surface, ready to sink your product roadmap.

Here is what actually lives beneath the surface.

The Hidden Costs of Building In-House

1. Data Normalization and Pagination

Building an integration isn't just moving JSON from point A to point B. Every SaaS platform structures data differently. What you call a "User," Salesforce calls a "Contact," Zendesk calls a "Requester," and Jira calls an "Assignee." Your team has to write custom mapping logic for every single platform.

Pagination is equally messy. Some APIs use cursor-based pagination, others use offset-based pagination, and some rely on page numbers. Your engineering team must build custom abstraction layers to handle these discrepancies. (If you want to see how deep this rabbit hole goes, read our breakdown on building a declarative pagination system to normalize 250+ APIs into a single format).

2. OAuth Management and Race Conditions

Authentication is the most fragile part of any integration. Most modern SaaS applications use OAuth 2.0, requiring a complex dance of authorization codes, access tokens, and refresh tokens.

The real headache begins with token expiration. Access tokens expire frequently. Your system needs to intercept 401 Unauthorized errors, pause the current job, use the refresh token to get a new access token, update your database, and retry the original request.

If you have multiple background workers trying to sync data simultaneously and a token expires, you hit a race condition. Multiple workers try to refresh the token at the same time, the API provider invalidates all tokens, and your customer is forced to manually re-authenticate.

3. Rate Limits and Exponential Backoff

No SaaS platform lets you pull data at unlimited speeds. They protect their infrastructure using rate limits, and every platform enforces them differently:

• Shopify uses a leaky bucket algorithm.
• HubSpot limits requests per second and per day.
• Salesforce limits concurrent API requests.

When you hit a limit, the API returns a 429 Too Many Requests error. A naive integration will simply crash or drop the data. A production-grade integration requires implementing exponential backoff and retry queues. You have to parse the Retry-After headers (which are formatted differently by every provider), pause your workers, and safely resume later without losing data.

Here is a look at the boilerplate code required just to safely make a request in-house versus using the official @truto/truto-ts-sdk.

// The In-House Way: Handling Auth, Retries, and Pagination
import fetch from 'node-fetch';
 
async function fetchContactsSafely(tenantId) {
    const maxRetries = 5;
    for (let attempt = 0; attempt < maxRetries; attempt++) {
        const token = await getValidTokenFromDb(tenantId); // Custom logic with DB locks
        
        const response = await fetch('https://api.salesforce.com/v53.0/query/?q=SELECT+name+FROM+Contact', {
            headers: { 'Authorization': `Bearer ${token}` }
        });
        
        if (response.status === 200) {
            return response.json();
        } else if (response.status === 401) {
            await refreshOauthToken(tenantId); // Handle race conditions here
            continue;
        } else if (response.status === 429) {
            const retryAfter = parseInt(response.headers.get('Retry-After') || 2 ** attempt);
            await new Promise(res => setTimeout(res, retryAfter * 1000)); // Blocks the worker
            continue;
        } else {
            throw new Error(`API Error: ${response.status}`);
        }
    }
    throw new Error('Max retries exceeded');
}

// The Truto Way: Using the official TS SDK
import Truto from '@truto/truto-ts-sdk';
 
const truto = new Truto({ token: process.env.TRUTO_API_TOKEN });
 
async function fetchContactsWithTruto(tenantId) {
    // The SDK automatically normalizes query parameters,
    // handles token refreshes, and implements exponential backoff 
    // for rate limits under the hood.
    const contactsCursor = await truto.unifiedApi.list({
        unified_model: 'crm',
        resource: 'contacts',
        integrated_account_id: tenantId
    });
 
    const contacts = [];
    for await (const contact of contactsCursor) {
        contacts.push(contact);
    }
    return contacts;
}

4. API Versioning and Silent Breakages

APIs are living organisms. Providers constantly add new features, change data types, and deprecate old endpoints.

If you build integrations in-house, you are committing to infinite maintenance. Your engineering team must monitor changelogs and schedule refactoring sprints whenever an API version is deprecated. If you miss a deprecation notice, the integration breaks silently in production. You usually find out when an angry customer submits a support ticket.

Pros and Cons of Building In-House

Let's be honest: building in-house isn't always the wrong choice. It depends entirely on your use case.

Pros of Building In-House:

• Total Control: You own the entire data pipeline end-to-end.
• Deep, Niche Access: If you need to access highly obscure, undocumented endpoints that a unified API provider hasn't mapped yet, building natively gives you that access.
• No Vendor Reliance: You aren't dependent on a third-party middleware provider's uptime (other than the end SaaS platform itself).

Cons of Building In-House:

• Massive Engineering Drain: Your best engineers spend their time reading third-party API docs instead of building your core product.
• High Maintenance Debt: Every integration you build is a permanent tax on your engineering team's future velocity.
• Infrastructure Costs: Building polling infrastructure, dead-letter queues, and worker nodes drives up your AWS/GCP bills.

Showing the Math: The True Cost of In-House Integrations

Let's look at the actual numbers. We'll assume a conservative blended rate of $100/hour for a mid-level software engineer.

The Cost of 1 Integration

• Initial Build: 40 hours = $4,000
• Maintenance (API updates, bug fixes, monitoring): 10 hours/month = 120 hours/year = $12,000/year
• Total Year 1 Cost: $16,000

Spending $16,000 to unblock a massive enterprise deal makes sense. But SaaS products rarely need just one integration.

The Cost of 10 Integrations

Most B2B SaaS products end up needing somewhere between 5 and 15 integrations to serve their first cohort of customers - one CRM, one ticketing tool, a couple of accounting platforms, a few HRIS options.

• Initial Build (10 x 40h): 400 hours = $40,000
• Maintenance (10 x 120h): 1,200 hours/year = $120,000/year
• Total Year 1 Cost: $160,000

This is the tier where most teams underestimate the drag. Ten integrations is roughly one full-time engineer permanently tied up on third-party API maintenance instead of product work.

The Cost of 50 Integrations

To be competitive in categories like HR, CRM, or ticketing, you often need to offer dozens of integrations.

• Initial Build (50 x 40h): 2,000 hours = $200,000
• Maintenance (50 x 120h): 6,000 hours/year = $600,000/year
• Total Year 1 Cost: $800,000

At 50 integrations, you have accidentally built an entire integration company inside your own startup. You are dedicating three full-time engineers purely to maintaining third-party APIs.

Notice the pattern: in-house cost scales linearly with the number of connectors, while a unified API stays roughly flat. Every integration you add in-house widens the gap.

The Build vs Buy TCO Calculator

The section above uses a $100/hour rate and simple averages to keep the math readable. Real total cost of ownership has more moving parts. Here is the calculator you should actually run before committing engineering hours to the build native integrations vs buy unified API decision.

The formula:

Build TCO (over N years) =
    (I × H_build × R)                     // initial build
  + (I × H_maint × R × N)                 // ongoing maintenance
  + (Infra_monthly × 12 × N)              // queues, workers, monitoring, storage
  + (Incidents × Cost_per_incident × N)   // outages, missed SLAs, support drag
  + Opportunity_cost                      // roadmap features that slipped

Buy TCO (over N years) =
    (Platform_fee × N)                    // unified API subscription
  + (H_one_integration × R)               // one build against the unified interface
  + Customization_cost                    // per-account overrides, if any

Where:

• I = number of integrations in the portfolio
• H_build = hours to build one integration end to end
• H_maint = hours to maintain one integration per year
• R = fully loaded hourly engineering rate
• N = planning horizon in years

Ranges to plug in (from independent sources, not vendor marketing):

• R (fully loaded rate). US software engineer salaries run from $82,460 at the 10th percentile to $214,670 at the 90th percentile, with the middle band between $105,210 and $171,980 according to BLS OEWS 2025 data. Add 30-40% for benefits, hardware, and overhead, and you land at roughly $130-$220 per productive hour. Bessemer's State of the Cloud 2026 puts the median SaaS engineering hour fully loaded at $145. Use $150/hour as a defensible middle number.
• H_build. 40-80 hours for a straightforward REST API with prior experience. 150-300+ for Salesforce, NetSuite, or anything with SOQL, SOAP, or sync conflict resolution.
• H_maint. The industry benchmark is 15%-25% of the original development cost per year, per ScienceSoft's software maintenance research, and Bessemer 2026 puts custom integration median maintenance burden at 18% of original build cost annually. On a 60-hour build that is 9-15 hours per year, and it compounds as each vendor ships breaking changes.
• Incidents. This is the variable most build estimates miss entirely. An academic study of REST API deprecation found that among versions introducing breaking changes, only 12.7% included any deprecation notice (Yang et al., ICSME 2020), meaning most of the time your first signal is a failed sync and a support ticket. Budget for at least one silent breakage per integration per year in a mature portfolio.
• Infra_monthly. Background workers, retry queues, dead-letter storage, webhook receivers, secrets management, and monitoring. Roughly $50-$100 per integration per month at low volume, more once you cross millions of records.
• Opportunity cost. A typical enterprise with 20 SaaS applications has 30 to 50 active integrations, each requiring regular maintenance, and this permanent engineering tax consumes 2 to 3 full-time engineers who could otherwise be building products. For a Series B startup with 40 engineers, dedicating 3 to third-party API upkeep is a 7.5% product velocity hit.

A calculator you can run in a spreadsheet:

Even at a $60K/year platform fee - a realistic mid-market unified API price - the buy path lands roughly $66K cheaper over three years for the same 10 integrations, and the delta widens with every connector you add. And that ignores the opportunity cost of the freed-up engineering hours.

Case Study: A Mid-Market SaaS at 12 Integrations

To make the unified API build vs buy math concrete, here is a representative walkthrough for a Series B B2B SaaS with 40 engineers, HRIS and CRM connectors on the roadmap, and a 3-year planning horizon. The numbers use the independent benchmarks cited above, not internal Truto data.

The setup:

• 12 integrations requested by sales: 5 CRMs (Salesforce, HubSpot, Pipedrive, Zoho, Close), 4 HRIS (Workday, BambooHR, Rippling, Gusto), 3 ticketing (Zendesk, Intercom, Freshdesk).
• Blended engineering rate: $150/hour (Bessemer 2026 median).
• Annual maintenance: 18% of build cost.
• One silent breakage per integration per year, averaging 20 hours to diagnose and patch.
• Salesforce and Workday get an inflated build estimate (120 hours each) because SOQL, object relationships, and Workday's SOAP surface add real scope.

Path A: Build native integrations in-house

The direct cost is already north of $330K. The opportunity cost is where CFOs start asking questions - dedicating 1.5 engineers to integration upkeep on a 40-person team means 3.75% of headcount is permanently allocated to work customers do not directly pay for.

There is also a timing cost that does not show up in the table. Serializing 12 production-grade integration builds through a small team realistically takes 12-18 months. Sales feels every week of that delay.

Path B: Buy a unified API

The delta: roughly $142,000 in direct 3-year savings, plus 1.5 engineers freed for product work, plus 10-16 months faster time-to-first-integration. With Truto specifically, the per-account customization line is handled through the platform, environment, and account override hierarchy, so bespoke Salesforce or Workday tenants do not force a code change in your product.

When the math flips back toward Build:

• You only need 2 or fewer integrations for the full 3-year horizon.
• The integrations are your product - you are selling the connector itself.
• You need endpoints so exotic that no unified provider covers them, and a passthrough or Custom API escape hatch is not enough.
• Regulatory or data-residency constraints prevent any third-party middleware from touching the traffic.

For everyone else in the 5-plus integration range, the build native integrations vs buy unified API math tips toward Buy well before year one closes, and the gap only widens as sales adds more connector requests.

The Buy Alternative: Unified APIs

The "Build vs. Buy" debate used to mean choosing between writing custom code or forcing your customers to use clunky third-party tools like Zapier. Today, the solution is the Unified API.

A Unified API normalizes data across hundreds of SaaS platforms into common data models. Instead of building 50 different integrations, your engineering team builds one integration against the Unified API.

Pros and Cons of Buying a Unified API

Pros of Buying:

• Speed to Market: Build one integration and instantly offer your customers dozens of platforms (Salesforce, HubSpot, Zendesk, etc.).
• Zero Maintenance: When an underlying API changes or deprecates an endpoint, the Unified API provider updates the connector. Your code never changes.
• Automated Infrastructure: Authentication, token refreshes, rate limits, and pagination are handled out of the box.

Cons of Buying:

• Vendor Reliance: You are adding a dependency to your stack. If the Unified API provider goes down, your integrations go down. (This is why choosing a provider with enterprise-grade SLAs and fail-safe architecture is critical).
• Abstraction Limits: Unified models cover 95% of use cases, but if you need highly specific, non-standard data, you might feel restricted. Note: Premium providers like Truto solve this by offering "passthrough" requests, allowing you to hit native endpoints directly through their auth proxy when needed.

The Strategic Advantage of Unified APIs

Unified APIs shift integration work from a code problem to a configuration problem. Instead of shipping a new deploy every time you add a connector, you plug into an interface that already knows how to talk to hundreds of third-party services. Here is what that shift actually buys a product team:

• One schema, many providers. A single GET /unified/crm/contacts call behaves identically whether the underlying account is HubSpot, Salesforce, Pipedrive, Zoho, or Close. Your product code stops branching on provider names, and your test surface shrinks accordingly.
• Auth, pagination, and retries as infrastructure. OAuth token refresh, cursor/offset/page/link-header pagination, exponential backoff on 429s, and idempotency on writes are handled by the platform. With Truto specifically, refresh tokens are rotated ahead of expiry so you never see a race condition between concurrent workers.
• Provider changes absorbed upstream. When a vendor renames a field, deprecates an endpoint, or ships a new API version, the unified API provider ships the fix once and every customer of that provider gets it for free. You stop scheduling reactive maintenance sprints.
• Per-customer customization without forking code. Truto's three-level override hierarchy (platform base, environment, and account) lets each customer inject their own field mappings, custom fields, or endpoint routing on top of the base schema. A non-standard Salesforce instance does not force a code change in your product.
• Normalized webhooks, not just reads. Provider events are transformed into canonical record:* events with signed outbound payloads, so your event-handling code stops branching on the shape of each vendor's webhook.
• Passthrough for the 5% of edge cases. When the unified model does not cover something you need, a Custom API endpoint routes an arbitrary request through the same auth and credential layer. You keep the escape hatch without maintaining a parallel HTTP client and OAuth stack.

The compounding benefit is engineering focus. Instead of your team owning the maintenance surface for 50 connectors, they own one integration surface and ship product features against it.

Decision Checklist: Build vs Buy

This is the one-page gut check for the native integrations vs unified API question. Use it before committing engineering hours - the more boxes you tick in one column, the clearer the answer.

Build native integrations in-house if you can check most of these:

• You only need to integrate with one or two specific platforms, with no roadmap to expand.
• The integration is your core product (you are selling the integration itself, not a product that uses it).
• You need deep access to undocumented, proprietary, or highly specialized API surfaces no unified provider exposes.
• You have dedicated integration engineers with headcount budgeted for permanent maintenance, not feature work.
• Your customers are willing to wait 6 to 12 weeks for each new connector.
• You already have battle-tested infrastructure for token refresh race conditions, retry queues, dead-letter handling, and webhook signature verification.
• Regulatory or data-residency constraints prevent third-party API traffic from leaving your VPC.

Buy a unified API if you can check most of these:

• You need to integrate with a category of tools (all CRMs, all HRIS platforms, all ticketing systems), not a single vendor.
• Sales is blocked on multiple integrations simultaneously and every week of delay costs deals.
• You want new integrations shipped in days, not months.
• You would rather your senior engineers work on your core product than on OAuth flows and rate-limit handlers.
• You need webhooks normalized across providers so your event pipeline does not branch per vendor.
• You are already maintaining three or more integrations and feeling the compounding drag on velocity.
• You need per-customer customization (custom fields, endpoint overrides, extra mapping logic) without shipping code per customer.
• You want an escape hatch (proxy or custom passthrough) for the rare non-standard endpoint that unified models do not cover.
• Your team is under 20 engineers and cannot absorb integration maintenance as a permanent tax.

Quick scoring: If you checked four or more boxes under Buy and fewer than three under Build, a unified API is almost certainly the right call. If the counts are close, the deciding factor is usually team size and integration count - anything past three integrations tends to tip the math permanently toward Buy, because maintenance cost scales linearly while a unified API's cost stays roughly flat.

The Verdict: When to Build vs. When to Buy

So, which route should you take?

Build in-house if:

• You only ever plan to integrate with one or two specific platforms.
• The integration requires deep, highly specialized functionality that falls completely outside standard data models (e.g., executing complex, multi-step proprietary workflows inside a legacy ERP).
• Your core product is an integration platform.

Buy a Unified API if:

• You need to integrate with a category of tools (e.g., "We need to integrate with all CRMs" or "We need to pull data from all HRIS platforms").
• You want to ship integrations in days, not months.
• You are tired of your engineering team acting as a maintenance crew for third-party APIs.

Your company's competitive advantage is your core product, not your ability to parse Salesforce's SOAP API or manage HubSpot's OAuth tokens. By leveraging a unified API, you can offer your customers the connectivity they demand while keeping your engineering team focused on what they do best.