Sales is not your bottleneck.

The contracts are signed. The customers are eager. And the go-live dates keep moving, because each one needs its own integration before it can start.

The natural response is to hire another integration engineer.

But that treats the symptom as the problem. The constraint is not how many integrations you can build at once. It is that the cost of the next one never goes down.

Why healthcare has no standard endpoint

In most industries, integration converges. You write to a handful of dominant APIs and the marginal customer is configuration, not engineering.

Healthcare does not converge. Every clinic, provider group, and data counterparty is bespoke: different EHR, different version, different enabled modules, different local extensions, different authorization posture, different appetite for letting you write anything back at all.

This is measurable, not anecdotal. In a national survey of digital health companies conducted by UCSF researchers with ONC support, the barriers reported as substantial were led by high fees for EHR API access (47%), lack of realistic clinical testing data (41%), access to the data elements that actually matter (40%), and availability of standards-based APIs from the vendor (38%). Source: Barker W, Strawley P, Rosner B, Adler-Milstein J, "A national survey of digital health company experiences with electronic health record application programming interfaces," Journal of the American Medical Informatics Association, 2024;31(4):866-876.

Read that list again. Fees, test data, access, and vendor posture. Only some of it is code.

The mechanism

When each integration is built as its own project, the work compounds in the wrong direction.

Every new counterparty adds a code path. Every code path adds a place for the next change to break. The team that owns integration number twelve is also carrying eleven, and the maintenance load grows faster than the team does.

So the second engineer does not halve the queue. They add coordination cost to a system that already has no shared shape.

What actually reduces the cost

The teams that escape this do one thing early: they stop treating each integration as a feature and start treating the *ability to integrate* as the product.

In practice that means a capability-port architecture, where the core system talks to an internal contract and each counterparty implements against it, rather than the counterparty's shape leaking into the domain. It means source-agnostic mapping. It means a repeatable EMR assessment run before commitments are made, so scope is known before a date is promised.

Be precise about the claim: this reduces avoidable rework. It does not eliminate the work. Authorization negotiation, absent APIs, workflow variance, and vendor drift are plausibly the larger half of the cost, and they are largely immune to how clean your code is. Anyone who tells you onboarding becomes a checklist has not done this.

The better question

Do not ask how many integrations the roadmap needs this year.

Ask whether the twelfth one will cost less than the third.

If the answer is no, the constraint is architectural, and hiring against it converts an engineering problem into a payroll problem without moving the ceiling.

Next step

If signed customers are queuing behind your integration backlog, that is an engineering-leadership decision before it is a staffing one. Book a fit review.