Every managed service provider has to deal with some sort of custom integration. This could be a Python script running on a server, a Groovy snippet inside a Jira automation, or a Zapier workflow set up by an intern.
These integrations share a common origin. A team needed two systems to exchange data, and building it looked cheaper than buying it. So they decided to build something quickly, but then the maintenance costs started to compound.
The real question now becomes who will maintain the integration in three years, and what happens when that person leaves.
This article walks through the hidden costs of in-house integration, the scenarios where building is the right call, the use cases where buying delivers better long-term value, and a framework for making the decision before you commit.
The Hidden Costs of Building It Yourself
The case for in-house development usually rests on three points: existing engineers, system familiarity, and avoided license fees. Those calculations rarely include what happens after the integration ships.
- Maintenance accounts for most of the lifetime cost. Industry estimates put initial development at roughly 30 to 40% of the total cost of ownership. The remaining 60 to 70% covers maintenance, rework, and incident response. Self-maintained integrations tend to exceed third-party tooling investment by 40 to 70% over their operational lifetime.
- API changes happen on someone else’s schedule. Jira Cloud, ServiceNow, Salesforce, and Azure DevOps revise their APIs independently. Authentication methods also depreciate as endpoints change. Each breaking change becomes unplanned work, often arriving close to a release deadline.
- Documentation falls out of date. The engineer who wrote the integration leaves. The README reflects the second-to-last version. New team members spend time reverse-engineering the integration code before they can safely modify it. In MSP engagements, the first weeks of an inherited-integration handover are typically spent on discovery rather than improvement.
- Custom scripts require constant updates. One IT lead summarized it in a recent post-mortem: “Configuring and fine-tuning integrations takes too much time, challenging for a small IT team. Custom scripts need constant updates, which stretches resources.“
- Field and workflow drift break integrations. Teams rename a status, then someone adds a custom field, which restructures the entire workflow. The integration either fails or, more dangerously, continues running with incorrect data. A support manager described the experience as “constant manual updates when teams change field names, statuses, or workflows.”
- Unnoticed failures create reconciliation projects. A field stops syncing, which means that the issue gets stuck in the pipeline for weeks. Now the team needs to fix the integration and reconcile the missing data. The integration appears to work until someone audits it.
When Building Makes Sense
Custom development remains the right answer in specific circumstances. Consider building in-house when one or more of the following apply:
- Your requirements are genuinely unique. The integration touches a proprietary internal system, a custom data model, or a regulated workflow with no off-the-shelf connector. The commercial market hasn’t solved your problem because your problem isn’t widely shared.
- Security or sovereignty constraints rule out third-party tools. Organizations with air-gapped environments, sector-specific compliance requirements, and government workloads sometimes prohibit running third-party integrations at the strategic business level.
- You have committed to in-house ownership. A single developer who can write the integration isn’t sufficient. You need a team prepared to own it for years, with documentation, runbooks, on-call coverage, and a clear succession plan.
- The integration is small, stable, and internal. You have just two systems you fully control with no plans to extend the integration to additional platforms or partners. A lightweight script handles this well and doesn’t justify a commercial platform.
If your situation matches these criteria, building is reasonable. If it doesn’t, the next section is worth reading carefully.
When Buying Makes Sense: Common Use Cases
The buy case becomes clearer when you look at the specific scenarios where DIY integrations consistently struggle. The following use cases come up repeatedly in client conversations.
Cross-Company Support Handoffs
A common request from MSPs and service providers: “We are currently working with one of our clients’ ServiceNow, giving them support for a SaaS platform. We’d like to integrate our Zendesk with their ServiceNow so we don’t need to work in two different systems.”
Neither company wants to fully open its environment to the other. A custom API connector requires both sides to coordinate every change, share credentials, and align release schedules. But this can be solved with a commercial platform that supports independent configuration on each side, which allows both companies to manage their own rules without coordinating every update.
Internal-Note and PII Separation
Healthcare, financial services, and regulated industries face strict requirements about which data can leave a system. A representative from a healthcare company wanted to keep all personally identifiable information from going to Jira.
Another team wanted to block internal Zendesk notes from leaving their instance.
Conditional field-level logic of this kind is where DIY integrations typically fail audits. An integration solution with scripting capabilities, like Exalate, handles selective synchronization through configuration rather than custom code.
Selective Ticket Routing for Multi-Tenant MSPs
MSPs serving multiple customers face a recurring requirement: they want the platform to be prescriptive, with only syncing tickets targeting a specific customer. At the same time, they don’t want customers to see or sync with another customer’s ticket for data protection.
Building this in-house means writing a custom access-control layer on top of two ticketing systems and maintaining it as customer requirements change. But when you buy an integration specialized for this scenario, you won’t have to deal with the nitty-gritty of configuration and maintenance.
Hub-and-Spoke Escalation Across Many Clients
Another MSP pattern features in organizations that have instances called ‘IOPs’. They also want their customer instances (let’s say there are 20 of them) to be able to escalate tickets to this IOPs instance.
Twenty custom point-to-point integrations create twenty maintenance burdens because every API change affects twenty connections. Adding a dedicated connector with AI-powered scripting makes the configuration a breeze without having to struggle with all that maintenance cost.
License-Reduction Scenarios
Some integrations pay for themselves through license savings. For a company with external development partners using Jira in the Atlassian cloud, they need to invite every developer from the partner, without paying for extra licenses.
Buying a commercial integration delivers value immediately without having to pay twice during development: once in engineering time, again in licenses, while the in-house version remains incomplete.
DevOps to ITSM Bridges
The classic Jira to ServiceNow scenario involves two teams with opposing motivations. Development teams optimize for change. A global manufacturer reduced work resolution time by 40% after integrating the two platforms, allowing engineers to receive ServiceNow tickets as Jira work items without manual handoff.
Custom-built bridges between these systems often originate from one side and impose its workflow on the other. But independent configuration on each side allows each team to keep its own rules and share only what it chooses to share.
A Decision Framework: Build vs Buy Integrations
The following questions help clarify which approach fits your specific situation. Work through each category honestly before committing to building or buying.
Scope questions:
- Is the integration connecting two systems or more than two?
- Does data flow in one direction or bidirectionally?
- Does the integration cross company boundaries?
- Do you need to keep internal notes, PII, or specific ticket types from leaving your instance?
Lifecycle questions:
- Who maintains the integration long-term if the original developer leaves?
- How often do the connected systems revise their APIs?
- What happens when one side renames a status, adds a custom field, or migrates platforms?
- Does the integration have documented runbooks, or does institutional knowledge live with one person?
Cost questions:
- What’s the fully-loaded engineering cost across build, maintenance, documentation, and on-call coverage?
- What’s the business impact of a failed sync that goes undetected?
- Are you reducing total cost, or shifting it from a license line item into engineering capacity?
Strategic questions:
- Is integration a differentiator for your business?
- What’s the strategic rationale for building it in-house?
Honest answers to the lifecycle and cost questions usually point clearly in one direction.
Find out how much adding an integration solution would cost your business.
What We’ve Observed Across Client Engagements
Several patterns emerge consistently across MSP engagements and integration handovers.
- Most in-house integrations get replaced in a few years. The trigger is usually a personnel change, an acquisition, or a major API revision. The original integration didn’t fail because the engineer wrote bad code. It failed because the organization wasn’t structured to maintain it long-term, and the cost of fixing accumulated issues eventually exceeded the cost of replacement.
- Cross-company integrations are the most consistent buy case. Both sides want to keep their own workflows. Neither wants to grant the other admin access. Custom builds rarely model the trust boundary correctly because they’re designed from one side’s perspective. The side that built the integration wins by default until the other side declines to continue cooperating.
- License reduction often justifies the purchase before deployment. A surprising number of integration conversations begin as “we need to sync these systems” and resolve to “we’re paying for licenses our partners don’t need.” Tools that allow external collaborators to work in their own instance frequently recover their cost before full rollout.
SPK’s MSP model uses Exalate as a commercial integration layer because it allows independent configuration on each side, which is the requirement custom builds typically fail to satisfy.
Measurable results across client engagements include roughly 5 hours saved per engineer per week, a 25 to 40% reduction in time to resolution, and a 70 to 90% reduction in manual handoffs.
Choosing the Layer to Own
The build vs. buy decision ultimately comes down to a different question: what should your engineering team spend its time on?
Most of the value in modern software work lives in the product or service running on top of the integration layer.
Building everything in-house signals that integration is a strategic differentiator only for a few organizations. However, buying the integration layer frees engineering capacity for work that actually distinguishes the business.
The teams that consistently deliver are the ones that recognize which layer to own and which to delegate.
To see how Exalate works for your use case, start a free trial right away.
If you’re working through this decision and want a second perspective on your specific stack, reach out to SPK experts to discuss your use case.
