What It Actually Costs to Build an Integration (A Cost Model, Not a Range)

Search this question and you'll get numbers between $2,000 and $150,000. Both ends are real. Neither helps, because the published ranges hide the two variables that actually determine where you land: which third-party API you picked, and how many of your customers will eventually connect it.

This article gives you the model instead of the range. You'll get a way to score an API's difficulty before you write code, a fully loaded hourly rate you can defend, a three-year cost breakdown for a realistic integration, portfolio math for a full roadmap, and a build-vs-buy framework that doesn't assume the answer.

One thing to keep in mind while reading: most cost estimates published on this topic come from companies selling integration platforms, including the most widely quoted one. Merge's frequently cited $50,000-per-integration figure is built on 150 build hours, 300 maintenance hours, a $150,000 engineer salary, and 150 support tickets a year at two hours each. Those assumptions are reasonable for some integrations and badly wrong for others, and the number is worth exactly as much as the inputs behind it. So this article shows all of its inputs, and you should substitute yours.

"We need a Salesforce integration" can describe an afternoon of work or two engineer-quarters. Most estimating failures start here, not in the code.

Baseline hours cover design, build, test, documentation, and internal enablement — not just the pull request. They assume a mid-level API, which is what the next section is for.

The tier ladder is also a scoping lever. A surprising share of customer integration requests are satisfied by Tier 0 or Tier 1. Teams default to Tier 2 because it sounds more complete, then spend a quarter building bidirectional sync that three customers use in one direction.

Adding integrations to your SaaS product

Two Tier 2 integrations built by the same engineers, in the same week, can differ by 3x in effort. The variance lives almost entirely in properties of the third-party API — and those properties are knowable in an hour of reading documentation, before anyone commits to a sprint.

Score each factor 1, 2, or 3. Total is 10 to 30.

Estimated hours = baseline hours for the tier × difficulty multiplier.

Worked example. A two-way contact-and-deal sync with a mainstream CRM that offers free developer accounts, webhooks, and custom properties scores roughly: auth 2, tenancy 1, change feed 1, data model 2, rate limits 2, write semantics 3, test environment 1, partner gating 2, stability 1, permissions 2 — 17, Standard, ×1.0. At a Tier 2 baseline of 220 hours, you're estimating 220 hours.

Now score a deep integration with an enterprise ERP: per-tenant app registration (3), on-prem versions in the field (3), polling only (3), user-definable records (3), shared quota (3), full upsert semantics (3), gated sandbox (3), paid partner program (3), unversioned edge behaviour (2), IT-mediated install (3) — 29, Hostile, ×2.2. Against a Tier 3 baseline of 550 hours, that's roughly 1,200 hours. Same company, same engineers, 5x the cost of the CRM integration.

That gap is the entire answer to "how much does it cost to build an integration," and no published range captures it.

Salary is not cost. Use a fully loaded rate, or your estimate will be off by 40% before you start.

The U.S. Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 as of May 2025. Load it with payroll taxes, benefits, equipment, software, and management overhead — conventionally a 1.25x to 1.4x multiplier — and you're at roughly $170,000 to $190,000. Divide by deliverable engineering hours, which is closer to 1,600 a year than 2,080 once you subtract PTO, holidays, meetings, on-call, interviews, and context switching.

The examples below use $110/hour for engineering and $85/hour blended for support work that mixes customer success time with engineering escalation. Swap in your own.

Year 1 cost of one integration =
    (build hours × engineering rate)
  + (fixed maintenance hours × engineering rate)
  + (connected tenants × support hours per tenant × blended support rate)
  + partner, listing, and sandbox fees
  + attributable infrastructure and observability

Applying it to the Standard CRM sync above — 220 hours, growing from 40 to 250 connected customers over three years:

Three-year cost: roughly $90,000. The build is 27% of it.

That ratio is the point. Teams approve integrations on the build number and are surprised by everything after.

Almost every article on this topic reuses the enterprise-IT rule that annual maintenance runs 15–25% of the original build. That rule comes from internal systems integration, where there is exactly one instance of the integration, running against one configuration of one CRM, used by one company.

A customer-facing integration is a different object. You are operating N instances, one per tenant, each with its own OAuth grant, its own field mappings, its own admin who revokes a scope on a Friday, its own volume against a shared rate limit. Maintenance splits into two terms that behave differently:

• Fixed, per integration, per year — API version migrations, deprecated endpoints, scope changes, auth flow changes, keeping the connector current. Typically 30–120 hours depending on the vendor's release discipline. Independent of how many customers use it.

• Variable, per connected tenant, per year — token expiry, permission drift, data that doesn't map cleanly, duplicate resolution, "the sync stopped last Tuesday." Typically 0.5–2 hours per connected tenant per year for a Tier 2 integration, mostly landing on support with an engineering escalation tail.

The consequence is counterintuitive: your most successful integration is your most expensive one. A connector nobody adopts costs you its fixed maintenance and nothing else. A connector half your base turns on costs you the fixed term plus a support line that grows with revenue. Budget accordingly, and price accordingly.

Single-integration math understates the problem, because integrations don't arrive alone. Research from Pandium found the median SaaS company offers around 15 integrations, with app-platform companies running into the hundreds.

Take a realistic mid-stage roadmap of 12 integrations:

At $110/hour:

• Build: ~$306,000, or about 1.7 engineer-years of capacity.

• Fixed maintenance: ~$79,000/year — roughly half an engineer, permanently allocated, before a single support ticket.

• Tenant support: at an average of 60 connected customers per integration, 720 connections × 1.2 hours × $85 ≈ $73,000/year.

Combined run rate: around $152,000 a year, or one full-time engineer, to keep twelve integrations alive. Not to add any. Not to improve any. To keep them working.

This is the number to put in front of a leadership team, because it's the one that changes decisions. The build is a project. The run rate is a permanent tax on roadmap capacity, and it compounds every time you say yes to a new logo on the integrations page.

Partner programs and marketplace listings. Deep integrations with enterprise platforms usually require joining a partner program, passing a security review, and often paying a revenue share. Salesforce is the clearest example: listing a managed package on AppExchange requires a mandatory security review with a per-submission fee, an annual listing fee for paid apps, and a percentage revenue share on sales through the channel. Published figures for the review fee currently conflict across sources — some cite $2,550 and others $999 following a 2023 change — so confirm the current amount in the Salesforce partner documentation rather than trusting a blog. The larger cost is usually time: multi-week review cycles with a meaningful first-pass failure rate, sitting directly on your launch date.

Test environments. Free developer sandboxes are a gift. Where they don't exist, you're either paying for a seat on the platform you're integrating with, negotiating partner access, or — worst case — testing against a customer's production instance, which is a support incident waiting to be scheduled.

Compliance scope. Every integration that touches customer data in a new third-party system expands your security review surface. Vendor questionnaires get longer, subprocessor lists grow, and your SOC 2 scope moves. This is real cost, usually paid in security-team and legal hours rather than engineering hours, and it's almost never in the estimate.

Observability. Per-tenant logging, sync status, and replay tooling is the difference between "the sync is broken" taking 10 minutes or 4 hours to diagnose. Teams skip it on integration one and pay for it on integration five. Build it as shared infrastructure, cost it once, and amortize it.

Customer-facing documentation and enablement. Setup guides, permission requirements, troubleshooting articles, sales enablement, and demo environments. Budget 10–15% on top of engineering for anything customers self-serve.

Sunset cost. You cannot quietly delete a customer-facing integration. Deprecation means migration paths, notice periods, and account-by-account conversations. Assume anything you ship, you own for years.

The buy side is genuinely cheaper for most teams at most scales. But "cheaper" depends entirely on the billing unit, because the billing unit determines whether your platform bill tracks your revenue or outruns it.

Note that most embedded integration platforms don't publish pricing at all. Paragon, Prismatic, Workato Embedded, and Tray Embedded are all quote-based, which is itself a budgeting cost — you cannot model them without a sales cycle.

Pricing is as published at the time of writing and changes frequently. Verify on each vendor's pricing page before modelling.

Whichever model you pick, run this before signing:

Platform cost per connected customer per month
  ÷ integration-attributable revenue per customer per month
  = integration COGS ratio

Keep it under roughly 20% and integrations stay a margin-accretive feature. Push past 50% and you've built a business that resells someone else's infrastructure at cost.

The arithmetic is unforgiving in one specific case: per-account pricing against a low-ACV product. If your average customer connects two apps and you're paying $65 per linked account, that's $130 a month in COGS per customer. Charge a $50 add-on for integrations and every activation loses money. Sell $80,000 ACV to enterprises where each customer connects one app, and the same $65 is a rounding error against the deal it unblocks.

Neither model is wrong. They're priced for different shapes of business, and the mistake is picking one without doing the division.

Skip the generic advice. These six answers determine the outcome.

1. Is the integration your product, or plumbing for your product? If a customer would name the integration as a reason they bought — a data platform whose warehouse connectors are the value — build it. You need control of the semantics, the performance envelope, and the roadmap. If it's the fourteenth CRM connector in a marketplace, it's plumbing, and plumbing is a commodity you should be renting.

2. How many integrations will you carry in 24 months? One or two, permanently: build. The portfolio math above never triggers. Five to fifteen: this is where the fixed maintenance term starts consuming a permanent fraction of an engineer, and where buying usually wins. Fifty-plus: you're building an app platform, and the question becomes which layers to buy, not whether to.

3. What do your customers' APIs score? Run the scorecard across your top ten requested integrations. A roadmap averaging 14–17 is buildable. A roadmap averaging 22+ means you'd be paying to solve problems a platform has already solved a hundred times.

4. How deep does the logic go? Reading normalized objects out of a category — HRIS, CRM, accounting — is what unified APIs are for. Letting your customers build their own multi-step workflows across their own stack is what an embedded integration layer is for. Arbitrary custom business logic against one API's exact semantics is what building is for. Choosing the wrong layer costs more than choosing the wrong vendor.

5. What's your data residency and compliance posture? Some platforms cache customer data; some proxy it without storing it; some can be self-hosted. If you sell into healthcare, finance, or the public sector, this constraint can eliminate most of the market before price enters the conversation.

6. What is the pipeline actually worth? The cost of not shipping is the missing side of every build-vs-buy spreadsheet. Estimate it directly:

Annual blocked pipeline
  = deals per quarter where the integration is a stated requirement
  × the win-rate delta with vs. without it
  × average contract value
  × 4

Add renewal risk: accounts at renewal citing the gap × ACV × probability the gap tips them. Survey data from the State of SaaS Integrations report (published by Partner Fleet, Paragon, and PartnerStack) suggests integrations come up in a majority of sales conversations — treat vendor-sponsored survey figures as directional, but the direction is right. If the blocked pipeline dwarfs the build cost, stop optimizing the build cost and ship something.

Where building genuinely wins: a small number of strategically important integrations, a team with real API expertise, a compliance posture that rules out third-party data handling, or a unit economics profile where per-account platform pricing would eat the margin on the feature.

Two things happened at once, and they push in opposite directions.

Coding assistants compressed authoring. Writing the connector — the client, the pagination loop, the mapping layer — is meaningfully faster than it was two years ago. Realistically this cuts the build term, the smallest term in the three-year model, by some fraction. It does not touch the fixed maintenance term, because an API deprecation still requires someone to notice, decide, migrate, and verify. It does not touch the per-tenant support term at all, because that work is diagnostic and customer-facing.

If your estimate assumes AI cuts total integration cost by half, re-read the three-year table. The build was 27%.

Agent products inverted the breadth-depth tradeoff. A traditional SaaS integration goes deep on a few apps. An AI product that takes actions on a user's behalf needs shallow write access across dozens or hundreds of apps, each with per-user auth, each with an audit trail, each with permission scoping. Depth per app collapses; count explodes.

That shift makes the fixed maintenance term dominant, which is exactly the term platforms exist to absorb. It's also why MCP has become the connective tissue for this class of product: a standard way to expose tools to a model beats hand-writing a tool schema per app per product.

This is where viaSocket fits for teams in that position — it exposes an embeddable integration layer in three modes: your agent calling user-connected apps as tools, your backend triggering user-built workflows via webhook, or your users building multi-step automations inside your product against a catalogue of pre-built apps. The relevant cost property is that it's billed on active users and tasks rather than per connected account, so the bill tracks usage rather than multiplying with every app each customer turns on. Whether that model suits you is the gross-margin division above, not a matter of preference.

1. Pricing the happy path. The demo takes a week. Token refresh failures at 3am, partial syncs, rate-limit backoff, duplicate resolution, and a customer's admin revoking a scope take the other seven. Estimate the failure modes, not the flow.

2. Treating maintenance as a percentage of build cost. Covered above. Model it as fixed-per-integration plus variable-per-tenant, or you will systematically underfund your most successful connectors.

3. Extrapolating from integration number one. The first integration carries the platform cost — auth storage, secrets, job scheduling, retry semantics, observability — and looks expensive. The second looks cheap because it reuses all of it. The tenth is expensive again, for a different reason: you've exhausted the easy APIs and you're into the long tail.

4. Ignoring the tenant multiplier. Per-tenant field mappings, per-tenant quirks, per-tenant quota. Anything that scales with connected customers has to be in the model explicitly.

5. Counting only engineering hours. Support, documentation, security review, sales enablement, and partner management are 20–40% on top of the engineering number for anything customer-facing.

6. Forgetting you can never turn it off. Every integration you ship is a permanent obligation with a migration cost attached. "We'll deprecate it if it doesn't get traction" is not a plan you'll execute.

7. Assuming your team's estimate accounts for the API. Engineers estimate their own work accurately and the third-party's behaviour optimistically. The scorecard exists to make that bias visible before the sprint, not after.

1. Name the tier. Notify, Read, Sync, or Deep. Write down what's explicitly out of scope.

2. Score the API. Ten factors, 30 minutes with the docs, one number.

3. Multiply. Baseline hours × difficulty multiplier = build hours.

4. Set your loaded rate. Salary × 1.3 ÷ 1,600.

5. Add fixed maintenance. 30–120 hours a year, based on the vendor's release cadence and your scorecard's stability line.

6. Project connected tenants across three years, then multiply by 0.5–2 support hours each.

7. Add the invisible items. Partner fees, sandbox costs, docs, security review, observability.

8. Run it against the buy side. Take your three-year total, divide by 36, and compare to the monthly platform cost at your projected customer count — using each vendor's actual billing unit, not their headline price.

If steps 1 through 8 take longer than an afternoon, you've found a Tier 3 integration and you should run a discovery spike before promising anyone a date.

Two figures from the model above matter more than any headline range.

The first is that the build is roughly a quarter of what an integration costs over three years. Approving integrations on the build estimate is why teams that budgeted carefully still end up surprised.

The second is that twelve integrations consume about one full-time engineer a year just to keep working — before you add a thirteenth. That's the figure that changes roadmap conversations, because it converts an ambiguous "integration debt" complaint into a headcount number a leadership team can act on.

Neither figure argues for building or for buying on its own. What they argue for is modelling the per-tenant term explicitly, whichever way you go, and pricing integrations so the term is covered. If you build, you're funding it out of engineering capacity. If you buy, you're funding it out of gross margin. Both are defensible. Paying it without having planned for it is the expensive option.

If you're at the point of comparing that run rate against a platform bill, viaSocket Embed publishes its pricing and offers a free sandbox tier, so you can put a real number next to your own before committing to a sales cycle

Read More