Building Integrations In-House: When It's Worth It, When It Isn't

November 10, 2025

Updated June 2026

Integrations aren't optional anymore. SaaS customers expect your product to connect instantly to their existing stack — CRMs, HR systems, accounting tools, cloud storage, messaging.

Those integrations aren't features. They're table stakes for winning and keeping customers.

The real question is how you deliver them: do you build integrations in-house, use an embedded iPaaS, or buy through a unified API? This post breaks down all three, the trade-offs, the costs, and where each makes sense for B2B SaaS teams.

Why this decision matters

Across the SaaS market, companies are using hundreds of integrations to drive adoption and retention. Integrations now directly affect:

• Close rate — buyers choose products that just work with their existing stack
• Retention — users rarely churn from products tightly embedded in their daily workflows
• Expansion — cross-product analytics and AI features depend on clean, normalized data

Integration strategy has shifted from a technical task to a core GTM enabler. The architectural choice you make on day one determines what your engineering team spends time on for the next five years.

The three real options

For a B2B SaaS company, the realistic alternatives to building integrations in-house fall into three categories:

Build in-house. Your engineers write and maintain every integration directly against each vendor's API. Full control, full maintenance burden.

Embedded iPaaS. A hosted integration backend plus a white-labeled UI so your customers can configure connections inside your product. Examples include Prismatic, Paragon, Workato Embedded, and Tray Embedded. You design workflow templates; the iPaaS hosts and monitors them.

Unified API. A single normalized API across many third-party apps in a category — CRM, HRIS, ATS, accounting, ticketing. Examples include Unified.to, Merge, Apideck, Nango, and Kombo. You build once against a normalized schema; the vendor handles each downstream integration.

A useful rule of thumb from Truto's architectural guide: if your application needs to understand and model the data, use a unified API. If your application needs to move data between tools based on user-defined rules, use embedded iPaaS. If your application is the integration layer, build in-house.

Option A: Build in-house

When it works:

• You only need a few integrations and they're deeply embedded in core product logic
• You have a dedicated integrations engineering team
• You operate in a regulated industry where third-party dependencies are not an option
• Your differentiation is the depth of one specific integration

What it actually costs:

This is where most teams underestimate the bill. Two recent benchmarks worth citing:

Knit's TCO analysis of customer-facing SaaS integrations finds a single production-grade integration costs roughly $50K–$150K in year one when you include build, QA, maintenance, support, and security overhead. Ongoing annual cost lands around $25K–$70K per integration in complex categories like HRIS, ATS, and CRM.

Leen's engineering breakdown finds an integration consumes roughly 460 engineering hours in year one — 240 hours of build, 120 hours of maintenance, 40 hours of security reviews, and 60 hours handling API changes. At US SaaS engineering rates, that's $20K–$40K of visible build cost alone, before ongoing maintenance and opportunity cost.

For a SaaS company maintaining 20 integrations, the fully-loaded engineering cost runs into seven figures over two years. Most of that isn't initial build — it's the maintenance tax that compounds with every new integration added.

The hidden cost most teams miss: opportunity cost. Every sprint your engineers spend fixing a broken API connection is a sprint not spent on your core product. For most SaaS companies, this is what actually tips the math.

Option B: Embedded iPaaS

When it works:

• Integrations themselves are part of the user journey, with a visual workflow builder inside your product
• You need multi-step workflows with conditional logic, retries, and scheduling
• Your customers want to configure their own automations without engineering involvement
• You need breadth across long-tail apps customers assemble into opinionated templates

What it does well:

Embedded iPaaS gives end-users a configuration interface — a workflow canvas they can use to wire up integrations themselves. Strong for products where the integration is the feature, like customer-success platforms where each customer needs a unique mix of CRM, support desk, and messaging integrations.

The trade-offs:

Integration logic lives in a proprietary UI/DSL outside your codebase. You can't version-control or unit-test workflows the same way you would code. Per-workflow maintenance compounds as your catalog grows. Lock-in is significant — moving away from an embedded iPaaS means recreating every workflow.

Pricing scales with workflow execution volume and tends to get expensive at scale.

Option C: Unified API

When it works:

• You need many integrations in the same category (CRM, HRIS, ATS, accounting)
• Your product reads and writes data into customer systems through your own UI, not theirs
• Your roadmap is more categories and more normalized data, not more workflow configuration
• You want integration logic in code, under your team's SDLC

What it does well:

One integration unlocks many vendors in a category. Adding new vendors becomes config-only work. The unified API vendor handles auth lifecycle, schema drift, rate limits, and vendor API changes. Your engineers work against a normalized schema in their own codebase.

The trade-offs:

The normalized layer may not surface every vendor-specific feature. Modern unified APIs handle this through custom-field support and raw passthrough, but evaluating depth against your specific use cases matters. Coverage depends on the vendor's roadmap.

Architecture varies meaningfully between vendors. Some unified APIs cache customer data on a sync schedule. Others — including Unified.to — proxy requests live to the source system with no customer payload data stored at rest. This choice affects data freshness, compliance scope, and whether the platform is suitable for AI agents that need to read current state on every request. We covered this in detail in the pillar guide on unified APIs.

Cost comparison: 20 integrations over 2 years

What 'build' really costs beyond payroll

Developer salaries are just the surface. The compounding costs hit through maintenance, reliability, and lost velocity:

• Auth logic per vendor — OAuth2 scopes, token refresh, expiry monitoring across every connected app
• Schema drift — mapping, migration scripts, testing, redeploys every time a vendor changes a field
• Monitoring and on-call — failed syncs, rate limits, retries, debugging across many integrations simultaneously
• Compliance scope — data stored at rest expands audit and liability surface for SOC 2, GDPR, HIPAA, CCPA, and PIPEDA
• Opportunity cost — features and performance work delayed while maintaining integrations

Every new integration adds compound maintenance debt. Small breakages multiply across customers, environments, and versions.

Where Unified.to changes the equation

Unified.to is a real-time unified API built on a stateless pass-through architecture. Every request hits the source API live — no caches, no replication, no sync delays. Across 460+ integrations and 27 categories.

Why architecture matters:

• Real-time by default — AI copilots, RAG, and analytics features depend on live data, not hourly syncs
• No stored customer data — nothing at rest on Unified's servers, which reduces compliance scope and removes a category of breach risk
• Consistent schemas — normalized models across categories, with custom fields available through the Metadata API
• Predictable scaling — usage-based pricing that tracks real demand, not seat or connection counts
• 22,566 callable MCP tools — AI agents can read and write across customer SaaS apps through the Model Context Protocol with one connection-scoped interface

Compliance footprint: SOC 2 Type II, GDPR, CCPA, HIPAA, and PIPEDA. The no-storage architecture means customer data never enters a regulated data store on Unified's side in the first place.

What it looks like in production:

Frankie Woodhead, CPTO at Thrive Learning, on choosing Unified.to to support 5M+ end users: "Given the breadth of integrations across categories and strong OAuth2 support, Unified was the right choice for Thrive. They allow us to scale integrations across millions of end users in a commercially sustainable way."

MyHub, an enterprise intranet product, replaced its manual HR onboarding process with 60+ Unified.to integrations in three months — with one engineer working part-time. CEO Steve Hockey on the deciding factor: "Unified.to's no-cache policy was a key factor in our decision. Their security-first approach is now part of our security and data privacy pitch to enterprise IT stakeholders."

The traffic math:

Per Unified's own pricing example: a SaaS product with 100 customers, one connected account each, and ~11 API requests per day per connection generates roughly 34,100 calls per month. On the Grow plan at $750/month, that's about $7.50 per customer.

For comparison: one engineer-month of fully-loaded SaaS engineering cost covers a full year of Unified at the Grow tier. If your team spends even a few weeks fixing broken integrations across the year, you've already broken even on the buy decision.

The long-term scalability question

If you build:

• Each new integration extends your maintenance horizon by years
• Your roadmap starts revolving around vendor API updates instead of core product work
• Engineers spend time on rate limits and expired tokens instead of building features
• Scaling from 5 to 50 integrations roughly multiplies headcount needs

If you use a unified API:

• Integration maintenance becomes infrastructure, not headcount
• Scaling from 5 to 50 integrations costs configuration time, not engineering time
• Your team stays focused on what differentiates your product

The real divide isn't cost — it's focus. Building means managing third-party APIs forever. Buying means integrations become part of your infrastructure.

How to decide for your product

A practical decision framework:

Build in-house if:

• Your product is the integration layer itself (e.g., workflow automation, RPA)
• You need deep proprietary logic across a small number of strategic systems
• You can afford a dedicated integrations engineering team and have the appetite to maintain it indefinitely

Use embedded iPaaS if:

• Your customers need to configure their own workflows through a visual UI inside your product
• You need multi-step automation with branching, conditional logic, and scheduling
• Long-tail app coverage matters more than normalized data depth

Use a unified API like Unified.to if:

• You want to ship integrations fast and scale category coverage
• You need real-time data for AI agents, analytics, or live workflows
• You value reduced compliance scope and predictable usage economics
• Your customers expect customer-facing integrations with native UX, not a workflow canvas

Many teams end up combining approaches: unified API for the high-volume normalized categories (CRM, HRIS, accounting), embedded iPaaS for long-tail customer-configurable workflows, and in-house for one or two strategic deep integrations central to product differentiation.

Before you decide: a build-vs-buy checklist

The three-bullet recap above is the fast read. If you're running an actual build-vs-buy review, these are the questions that surface real answers.

Strategy and differentiation

1. Is this integration capability core to your competitive advantage, or commodity infrastructure your customers expect?
2. Will this need to evolve in ways an off-the-shelf product is unlikely to support?

Cost and capacity

1. Do you have senior engineering capacity to build and maintain this for the next 3-5 years without derailing core product work?
2. How much is delayed time-to-market actually costing — lost deals, slower expansion, competitive ground?
3. What does the opportunity cost look like? What core product work would not get done if your engineers built this?

Scope and scale

1. How many integrations and categories will you realistically need in the next 24 months?
2. How fast is your customer base growing, and how does integration maintenance scale with it?

Risk and compliance

1. What reliability, security, and compliance standards must this meet — SLAs, audit, data residency, regulated frameworks like SOC 2, GDPR, HIPAA, CCPA, or PIPEDA?
2. How risky is vendor lock-in, and what would migrating away actually cost?

A common pattern across industry build-vs-buy frameworks: teams that lean toward "build" tend to underweight questions 3, 5, and 7. The initial build cost is visible; the multi-year maintenance tax and the opportunity cost on roadmap velocity are not. Both compound silently.

If most of these answers point toward "this is critical and we have the capacity to own it for years," in-house can be the right call. If they point toward "this is table stakes and we'd rather ship product," a unified API is usually the faster path.

The alternative to building integrations in-house

One real-time unified API across the tools your customers already use.

Connect once. Access 460+ integrations across 27 categories. No polling. No tokens to manage. No schema drift. No customer data stored.

Start your 30-day free trial →

Related reading:

• What Is a Unified API? — the architectural pillar guide
• Best Unified API Platforms of 2026 — category comparison
• Top Merge.dev Alternatives in 2026 — competitor comparison
• How Virtual Webhooks Unlock Real-Time Data — architectural deep dive