Integrations are 30% build, 70% everything after

Before starting Ampersand, I spent years as an engineering leader at fast-growing B2B companies (G2 among them) building and running integrations into enterprise systems of record. Now I run a company that builds integration infrastructure for other SaaS platforms, and I watch dozens of teams go through the same pattern from the other side of the table. The shape is consistent enough that I'll stake a number on it.

When you build an integration to an enterprise SoR, the visible build is roughly 30% of the total lifetime work. The other 70% happens every day after launch, scales with external variables you don't control, and most teams underestimate it by a factor of two or three. The split also gets worse over time. By year three it's closer to 20/80. By year five, for mature multi-tenant products, it can look more like 10/90. The argument breaks when the specific integration is unusually stable, the tenant count stays small, or the integration is core to your product in ways that make outsourcing strategically bad. I'll cover those cases too.

What the software engineering literature says, with appropriate hedges

The broader software maintenance literature is worth touching before I get into our own data. Lientz and Swanson's 1980 study of 487 data-processing organizations is the foundational work and is still cited. They found maintenance consumed roughly half of total development effort, with adaptive and perfective maintenance (changes driven by shifting requirements or environments) making up the majority, and corrective maintenance (bug fixing) a minority.

More recent summaries put the figure higher. The "60/60 rule" that circulates in engineering management writing (attributed to an essay in 97 Things Every Project Manager Should Know) pegs maintenance at 60% of lifecycle cost, with 60% of that being user-driven enhancements. A multi-case study on application lifecycles reported 21% of five-year cost in planning and development, 79% in ongoing work. IEEE software engineering surveys push long-lived enterprise systems to 70-80% maintenance.

Two caveats before leaning on these numbers. First, "maintenance" in this literature means all post-launch work: bug fixes, feature additions, security patches, platform migrations, refactors. When I claim integrations are "worse than average," I'm really claiming that adaptive maintenance (the subset driven by external change) is unusually heavy for integration code. That's a narrower claim than the headline ratio implies. Second, industry write-ups on this topic are often published by vendors who sell maintenance services or platforms. Merge.dev's 150-build-hours and 300-maintenance-hours-per-year figure is directionally consistent with what I see in practice, but Merge sells a unified API product, so the source is motivated. Take it as a data point, not a proof.

With those caveats on the table, here's how the work actually decomposes.

Upfront is connector building

Upfront work is the part a customer sees on day one. Integration logic for a given SoR, field mapping, auth flows (OAuth 2.0, API keys, JWT assertions, SAML for tenants whose IT team runs their own IdP), permission modeling, and the customer-facing setup UI that a tenant admin uses to connect without filing a ticket.

If you've done it before, a mid-complexity build (Salesforce, HubSpot) runs 150 to 250 engineering hours. NetSuite is heavier because SuiteQL, SuiteScript, and the REST API each cover a different slice of the data model. Workday and Epic can run 400+ hours before the partnership paperwork, and those partnerships can take six weeks on their own. Every one of those hours is legible. You can ticket it, demo the result, attach it to a milestone.

This is why the 30% is the number that lands in pitch decks and internal pricing models. It's the number engineers can estimate with any confidence at all. The problem is that this is the last time anyone writes a clean number down for this integration.

The runtime layer nobody demos

The moment the first tenant lights up, a second workload starts. Multi-tenant auth and token refresh at scale. Webhook delivery with retries and exponential backoff. Sync state and cursors per tenant so you know where you left off when a job dies at 4:17am. Rate-limit management across hundreds of end-customer orgs that share your app's API quota inside a given SoR. Dead-letter queues, replay mechanisms, per-tenant observability. None of this is integration-specific. All of it is where integration code actually fails in production.

A concrete version. A HubSpot token refresh job silently stops running for one tenant out of 400 because a background worker crashed on a malformed response, and the crash wasn't surfaced because the error budget for that job was already consumed by unrelated transient errors earlier in the day. For two days, that tenant's records don't sync. The customer's CSM notices because the end-customer notices. Now someone is reconstructing which records were touched during the gap, which weren't, and which got stale data written on top of fresh data. That is a Slack thread that runs for a full afternoon.

Rate limits produce a similar failure on a different axis. Salesforce's per-org daily API call limit starts around 15,000 calls per license per 24 hours for Enterprise. With 500 end-customer orgs connected to your app, you're managing 500 independent rate budgets, not one. Your bulk sync starts at 9am Pacific, East Coast admins log in at 9:15, a customer's weekly report job also kicked off at 9, and by 9:30 some tenants are out of budget. The right response is per-tenant token bucket accounting, prioritization between interactive and batch jobs, back-pressure into upstream queues, and circuit breakers that trip per-tenant. The wrong response is finding out when a customer's CRO can't pull pipeline on Monday morning.

A third failure category is cross-version behavior within a single SoR. Your tenants are not on the same Salesforce version at any given time because admins upgrade on their own schedule within the windows Salesforce permits. The runtime is simultaneously talking to tenants on v58 and v61 and something stale because one tenant's IT team froze upgrades during an ERP cutover. Branching per-tenant on SoR version is correctness-critical and easy to get wrong silently.

Adaptive maintenance is the work that never ends

Then the work that exists because the SoRs themselves change. API version migrations, schema changes in every tenant, new fields admins add without telling anyone, validation rules modified mid-quarter, new SoR features that customers want absorbed within a week of GA because their competitors already did.

Thumbtack moved from V2 to V4 with a 30-day deprecation window. Our customers didn't touch it; our team rewrote the connector and rolled it out before the cutoff. For a customer who had built the integration in-house, that would have been a quarter of engineering time pulled off the product roadmap to keep an integration that already existed still existing.

Salesforce runs three releases a year and commits to three years of API version support with one year of notice. In practice, that means you have some piece of the runtime within a year of losing support for an SoR feature you relied on. Summer '25 retired API versions 21 through 30, telegraphed since Summer '22. HubSpot does rolling v3 changes. Gong sunsets endpoints when its data model evolves. NetSuite changes SuiteScript behavior between major versions in ways that don't always show up in release notes. One migration per SoR per year is a reasonable planning assumption. Multiply by the number of SoRs in your catalog, and you have a continuous background workload.

The per-tenant side is harder because you can't schedule it. A mid-market Salesforce org has 400+ custom fields, and any of them can break an assumption overnight. Suppose your agent reads Account.Industry. On a Tuesday, an admin at one of your customer's end-customers changes Industry from a standard picklist to a required free-text field and adds a validation rule rejecting any value not in an internal taxonomy. Your next sync writes Technology, the validation rule rejects the write, the error cascades into the batch transaction, and the customer's pipeline view is stale by Thursday.

There's also the category of maintenance that exists because SoRs are less well-documented than they claim. NetSuite's REST API will accept a payload the docs say is valid and silently drop a field. Salesforce's Bulk API returns success on partial failures unless you ask for per-record results in a format that varies between Bulk v1 and Bulk v2. HubSpot's webhook payloads sometimes omit fields that other parts of the API treat as required. You learn this by incident. When the engineer who learned it leaves the team, the knowledge leaves with them unless you've been unusually disciplined about writing it down.

The integration is sold once, but it produces value every day an end-user touches a record, and the cost to keep it alive grows with every tenant that signs up.

When building in-house is the right call

I should name the cases where this whole argument points the other direction, because they're real and common enough to matter.

First, if you only support 1-2 SoRs and plan to stay there, the amortization math doesn't favor a platform. A focused Salesforce-only integration built by one engineer who knows Salesforce well is often cheaper and faster than onboarding to a runtime designed for 20+ SoRs. The platform's generality is overhead if you never use it.

Second, if the integration is your product, you probably shouldn't outsource the core. Gainsight, Troops, and any number of Salesforce-native AppExchange products are companies whose moat is deep, fast, opinionated behavior against one SoR. A platform doesn't help when the integration is the thing you're competing on.

Third, regulatory context matters. Adding a vendor to the data path expands your compliance surface. If you're running a HIPAA workload into Epic, or a SOX-relevant workflow through NetSuite, or anything touching FedRAMP, every additional processor in the chain is another audit scope line, another BAA, another vendor review. Sometimes the right answer is fewer parties in the path, even if the per-unit engineering cost is higher.

Fourth, latency and control. A multi-tenant runtime optimizes for aggregate throughput. If you need sub-100ms write behavior into Salesforce for a specific user flow, a dedicated integration you control end-to-end can beat a shared runtime. This is narrow, but it matters when it matters.

Fifth, the integration is read-only and the SoR is stable. Some integrations genuinely don't need much ongoing work. A one-way read from a vendor with a slow-changing API and a small tenant count can run for years with minimal intervention. The 30/70 ratio is an average. It hides a distribution where some integrations run at 80/20 and others at 5/95. The platform pitch is strongest for the middle of that distribution.

None of these cases describes most AI-agent startups I talk to. They describe enough of them that "always buy" is the wrong answer, and I don't want to be quoted as saying it.

Is the split 30/70 or 20/80?

The ratio is not a fixed constant. It depends on time horizon and tenant count. Rolling forward the 150-build-hours and 300-maintenance-hours-per-year assumption:

That table assumes maintenance stays flat at 300 hours a year, which is probably optimistic. Realistically, maintenance grows as tenant count grows and technical debt accumulates. The year-five share of 9% is the friendly version.

I want to be careful about how much weight this table carries. It's illustrative, built from one vendor's hour estimate projected forward under assumptions I chose. A reader who wants to push back can pick different inputs and get a different answer. What I'd stand behind is the direction, not the specific numbers: the build-to-maintenance ratio gets less flattering to the build side every year the integration is in production, for multi-tenant systems serving more than a handful of customers against moving SoRs.

Three structural reasons integration code runs heavier on the maintenance side than general software:

1. The work is driven by external events. SoR release schedules, your customers' admins, compliance changes in adjacent regulations, none of which respect your roadmap.
2. The cost scales with tenant count in a way most software does not. Per-tenant schema drift means every new tenant adds a marginal unit of ongoing work that never fully goes away.
3. The failure modes are customer-visible. If your CI pipeline is slow, no customer notices. If a Salesforce sync writes stale data into a pipeline record, the customer's CRO notices by Wednesday. This asymmetry means the ongoing work cannot be absorbed by letting things slip.

If you're pricing an integration at 30/70 internally, you're doing better than most teams, who implicitly price at 90/10 by treating integration as a one-time project that depreciates cleanly. If you're evaluating TCO over a 3 to 5 year horizon, 20/80 is closer to honest. At 5+ years and a few hundred tenants, closer to 10/90.

What we see across Ampersand's customer base

The pattern I described doesn't only come from my time building integrations at G2 and before. It also comes from what we see now across Ampersand's customer base, where we operate the runtime layer for other SaaS platforms integrating into systems of record.

A concrete shape of this: one of our customers, Hatch, runs 576+ of their own end-customer tenants on top of our runtime. Every one of those tenants has its own admin making schema changes on their own schedule, across Salesforce, HubSpot, Thumbtack, and a long tail of vertical tools. The 30/70 split we observe matches what our team actually does week over week on behalf of customers like them: one unit of effort writing new connectors, three units going into API wrangling, per-tenant schema drift handling, token refresh at scale, rate-limit management, and the rolling catalog of SoR version migrations that nobody schedules but everybody has to absorb.

Two honest caveats. First, companies that chose Ampersand already agreed with enough of the premise of this argument to pay for the conclusion. Companies that looked at us and built in-house are not in our dataset, and companies that built in-house successfully and quietly are particularly absent. A fully neutral population-level answer would include them, and we don't have their data. What I can say is that the pattern we see on our side matches what I lived at G2, which makes it less likely to be a sampling artifact.

Second, the 30/70 ratio is an average across a distribution. Some integrations run at 80/20 (stable SoRs, small tenant counts, read-only). Some run at 5/95 (write-heavy, high tenant count, SoRs with fast-moving APIs). The platform case is strongest for the middle of that distribution, which happens to be where most AI-agent and enterprise SaaS companies actually live.

What AI agents change

One thing worth separating out, since it's the context the piece opened on. AI agents that act against SoRs have maintenance characteristics that classical integration code doesn't.

Write actions are non-deterministic at the model layer. An agent that picks field X on Tuesday might pick field Y on Wednesday as the model updates or the prompt shifts. That isn't maintenance in the traditional sense, but it means your integration test suite needs to cover a larger behavior surface, and your observability needs to catch semantically-wrong-but-schema-valid writes.

Double-ended versioning. Both the model and the SoR can change underneath you. A regression can originate from either side. Debugging a production incident starts with knowing which one changed last, which is not always obvious.

Permission modeling at runtime. An agent acts on behalf of a user whose permissions are defined inside the SoR tenant. Honoring those permissions means reading them at the time of action, not at config time. Classical integrations can often get away with a service account; agent integrations frequently cannot. This shifts work from build-time setup to runtime enforcement, and runtime work is maintenance work.

There's a specific failure pattern here worth naming. Salesforce's sharing model (role hierarchy, sharing rules, manual shares, territory management) is evaluated at query time against the running user's permission set. If your agent runs under a service account, it bypasses all of that and can read records the end-user can't. If your agent assumes the user's identity via OAuth-on-behalf, it respects the permissions, but now your test matrix includes permission configurations for every tenant. We've seen tenant-specific permission configurations that required connector-level changes to handle correctly. That work is not something you do once. It repeats every time a customer's admin reorganizes their sharing model, which happens more often than you'd hope.

These push the maintenance ratio further from the build side, not toward it. They also push more of the maintenance burden into the runtime layer specifically, which is the layer that's hardest to build well and easiest to underestimate.

The takeaway

If you're sizing an integration build right now, separate the two line items. Price the connector as a project with a clear end. Price the runtime and the adaptive maintenance as ongoing headcount, scaled by tenant count, with a multiplier for each SoR you support. 300 engineering hours a year per connector is a reasonable floor; double it for Workday or NetSuite or tenant counts above a few hundred.

Then look at your specific case. If you're supporting one or two SoRs long-term, if the integration is the product, if regulatory context makes vendor concentration painful, build it. If none of those apply and you're serving multi-tenant enterprise customers, the ongoing-cost math usually points the other way. That's what I saw building integrations at G2, and it's what I see now watching other teams do the same thing on Ampersand's runtime.