Build vs Buy: Should You Build Your Own Integration Layer?
The build vs buy integration engine decision shapes healthcare integration costs for years. Buying an engine is not always right, and building is not always cheaper. Building makes sense for API-only estates, small interface counts and teams with existing integration skills. However, in-house builds consistently underestimate hidden work: retries, acknowledgements, monitoring, replay, audit logging and on-call support. This guide gives a real answer, including cases where building wins, and a break-even model with stated assumptions. Talk to our architects for a neutral assessment.
When Building Your Own Integration Layer Is Right
Building your own integration layer is sometimes the correct decision, and pretending otherwise helps nobody. Some organizations have simple, stable integration needs that an engine would overcomplicate. Others treat integration as core product intellectual property. The key is being honest about current needs and likely growth. If your situation matches several conditions below, building may be the better choice, especially with strong engineering practices and realistic support plans in place.
API-Only Estates
If you integrate only through modern FHIR or REST APIs, you may not need an engine's MLLP, batch and transformation features. Well-built services and an API gateway may be enough.
Small Interface Counts
With one to three stable interfaces and low volumes, a focused custom service can cost less than licensing, hosting and operating a full engine, provided reliability features are built properly.
Existing Integration Skills
Teams with experienced integration engineers understand acknowledgements, retries and monitoring. They can build reliable custom layers faster and with fewer hidden defects than teams new to healthcare integration. Skills shorten delivery.
Integration as Core Product
For some healthtech products, integration logic is a competitive advantage. Building gives full control over data models, performance and roadmap, which engines or platforms may not allow. Budget for long-term ownership.
Strict Deployment Constraints
Unusual deployment requirements, such as specific cloud architectures or embedded environments, may make engines difficult to run. Custom builds can fit constraints more naturally when engines cannot. Confirm constraints carefully first.
The True Cost of Building
Most in-house integration builds are estimated by counting development time for parsing and mapping. The real work sits elsewhere. Production integrations need reliable delivery, error handling, monitoring, replay, audit trails and people ready to respond when interfaces fail at night. Engines provide much of this out of the box. When building, you must create and maintain each capability yourself. Our HL7 integration experience shows these costs repeatedly. Each cost is explained below.
Acknowledgements and Retries
HL7 interfaces need correct ACK handling, retries, ordering and duplicate prevention. Getting these right under load and outages takes significant engineering time and careful testing with real partners. Edge cases take time.
Monitoring and Alerting
You need dashboards, queue metrics, error alerts and volume monitoring. Without them, failures remain silent until clinicians or billing teams report missing data days later. Monitoring must be built before the first production launch.
Message Replay
After downstream outages, teams must resend messages safely. Building replay requires message storage, selection tools, duplicate protection and audit trails, which many first builds omit entirely. Plan replay tooling from day one.
Audit Logging and Security
Integration layers hold large amounts of PHI. You must build audit logging, access control, encryption and retention, meeting HIPAA technical safeguards and customer security review expectations. See HIPAA technical safeguards.
On-Call and Maintenance
Someone must respond when interfaces fail, partners change formats or certificates expire. On-call coverage, upgrades and partner changes create ongoing costs that rarely appear in initial estimates. Budget for these costs yearly.
A Break-Even Model With Stated Assumptions
A simple five-year model helps compare building and buying. It is illustrative, not a quote, and your inputs will differ. The assumptions below use a fully loaded engineer cost of $150,000 per year, which varies by location and seniority. Replace every value with your own figures. The model also ignores opportunity cost, which often favors buying when engineers could otherwise build product features that generate revenue for the business. The model follows.
The Formula
Five-year build cost equals initial build effort plus five years of maintenance and on-call effort. Five-year buy cost equals implementation plus five years of licence, hosting and operations effort. Use your own inputs.
Build 5-yr cost = (initial FTE-years × FTE cost) + 5 × (ongoing FTE × FTE cost)
Buy 5-yr cost = implementation cost + 5 × (licence + hosting + ongoing FTE × FTE cost)Example Build Assumptions
Assume one engineer-year to build core capabilities, then half an engineer each year for maintenance and on-call. Five-year build cost becomes $150,000 plus $375,000, totaling $525,000. These figures are illustrative planning assumptions only.
Example Buy Assumptions
Assume $60,000 implementation, $30,000 yearly licence and hosting, and a quarter engineer yearly for operations. Five-year buy cost becomes $60,000 plus $337,500, totaling $397,500. These figures are illustrative planning assumptions, not quotes.
Reading the Result
In this example, buying costs less over five years. With fewer interfaces, lower maintenance or existing skills, building can win. Change assumptions honestly, and test several scenarios. Sensitivity matters most.
Factors the Model Misses
The model ignores interface growth, opportunity cost, hiring risk, vendor lock-in and time to market. Consider these qualitatively alongside numbers before making a final decision. Document these judgments for decision makers.
Buy, Build or Hybrid: Making the Decision
Many organizations choose neither pure option. A hybrid approach might use an engine for HL7 and file-based feeds while building custom APIs for product-specific workflows. Others start with custom code and adopt an engine once interface counts grow. The right decision reflects current needs, expected growth and team capabilities. Our Mirth Connect consulting and FHIR integration teams support engine, custom and hybrid architectures. The main options are explained below in turn.
When Buying Is Usually Better
Buy an engine when interface counts are growing, HL7 feeds dominate, uptime requirements are strict or internal integration skills are limited. Engines reduce hidden reliability and operations work. Skilled partners help too.
When a Hybrid Works Best
Use an engine for traditional feeds and custom services for product APIs. This combines reliable interface operations with flexibility where your product needs unique behavior or performance. Boundaries must stay clear.
Integration Engine Alternatives
Alternatives include integration platforms, managed services and cloud healthcare APIs. They reduce operational burden, but introduce subscription costs and dependency on provider coverage and roadmaps. Evaluate exit options before signing any agreement.
Designing for Future Change
Whatever you choose, keep integration logic modular behind clear interfaces. This lets you change engines, platforms or custom components later without rewriting your entire application. Modular designs reduce long-term migration risk.
Getting a Neutral Assessment
A neutral assessment compares options using your real interfaces, volumes and skills. Our healthcare API development team can model scenarios and recommend building when building is genuinely right. Recommendations are documented.
Frequently Asked Questions
Should we build or buy an integration engine?
Build when you have API-only integrations, few stable interfaces or experienced integration engineers. Buy when interface counts are growing, HL7 feeds dominate, uptime requirements are strict or skills are limited. Compare five-year costs, including maintenance, monitoring, replay, audit logging and on-call support, before deciding.
What are the hidden costs of building your own HL7 interface?
Hidden costs include acknowledgement handling, retries, ordering, duplicate prevention, monitoring, alerting, message replay, audit logging, security controls, certificate management, partner changes and on-call support. These capabilities often take more effort than parsing and mapping, and they continue costing money every year after launch.
When is building an integration layer the right choice?
Building is often right for API-only estates, small numbers of stable interfaces, teams with strong integration skills, products where integration is core intellectual property or environments with unusual deployment constraints. Even then, plan for monitoring, replay, audit logging and on-call support from the start.
What are alternatives to an integration engine?
Alternatives include integration platforms offering managed EHR connectivity, managed integration services, cloud healthcare APIs and custom-built services with API gateways. Each reduces or shifts operational effort, but introduces trade-offs in cost, flexibility, coverage and dependency on external providers and their roadmaps.
How do you calculate build vs buy break-even?
Estimate five-year build cost as initial development plus yearly maintenance and on-call effort. Estimate five-year buy cost as implementation plus yearly licence, hosting and operations effort. Use realistic engineer costs and interface growth assumptions, then consider opportunity cost, hiring risk and time to market.
Can we start by building and switch to an engine later?
Yes, if integration logic is modular and well documented. Many organizations start with custom services for a few interfaces, then adopt an engine as volumes grow. Keeping clear boundaries, consistent data models and good tests makes later migration much easier and less risky.
Want a Neutral Build vs Buy Assessment?
Our integration engineers are ready to help. Free consultation, no obligation.