When To Build Custom Integrations vs. Using Integration Platforms

Your engineer just shipped a Slack app that surfaces ServiceNow tickets in relevant channels. It took three days to build. Six months later, ServiceNow changed their API versioning structure, your Slack workspace reorganized, and the engineer who built it is on a different team. The integration still works, mostly, but no one’s entirely sure how the error handling works, and there’s a growing list of edge cases in a Notion doc somewhere.

This is the moment you start looking at integration platforms. Not because you can’t build integrations, but because you’re already supporting too many of them.

The conversation that follows usually splits along predictable lines. Developers argue that platforms add unnecessary cost for problems they can solve directly. Finance wants to know why you’re spending money on tools when you have a perfectly good engineering team. And you’re stuck trying to explain that the question isn’t about capability—it’s about what happens after the integration ships.

The maintenance burden nobody tracked

Custom integrations feel cheap when you’re measuring build time. Three days of engineering work. A week, maybe two for something complex. Approved in a sprint, shipped the next week, solves an immediate problem. The cost seems contained.

Then you start tracking what happens over the next twelve months. The integration breaks when ServiceNow updates their API. Someone needs to figure out why tickets stopped syncing. The engineer who built it is heads-down on a priority project, so someone else investigates. They spend two hours understanding the code, another hour reading API documentation, and thirty minutes making a fix. The integration works again. This happens quarterly.

A new team member joins and asks how the Slack integration works because they need to troubleshoot a ticket that didn’t surface properly. Nobody remembers the details. Someone digs through the code repository, finds the README that’s six months out of date, and explains it in a Slack thread that immediately gets buried. Three weeks later, a different new team member asks the same question.

Your service desk manager mentions that tickets sometimes don’t sync from Zendesk to Jira, but nobody’s sure why. Could be timing, could be field validation, could be the rate limiting logic. The engineer who would know is on vacation. Someone else tries to debug it, discovers the logging isn’t detailed enough to diagnose the issue, and adds “improve logging” to the backlog. The ticket sync continues failing intermittently.

This is the maintenance burden: not the three days to build, but the accumulated cost of keeping it running, transferring knowledge, debugging issues, and handling edge cases that emerge slowly over time. Most teams don’t track this cost because it’s distributed across people and happens in small chunks. An hour here, thirty minutes there, two hours next week. It feels manageable until you add it up across multiple integrations.

The actual cost isn’t the engineer hours—it’s the context switching and the knowledge fragmentation. Every custom integration creates a small pocket of specialized knowledge. When that knowledge lives in one person’s head, you have a single point of failure. When it’s distributed across a team, nobody has the full picture. The integration becomes a black box that works until it doesn’t, and fixing it requires archaeological work every time.

When the original builder isn’t coming back

You know you have an integration ownership problem when someone asks “who built the ServiceNow-Slack sync?” and the answer involves checking obscure documentation because the person isn’t on the team anymore. Not because they left the company, but because they moved to a different project six months ago and haven’t touched that code since.

The integration isn’t abandoned technically. It still runs. Tickets still sync, mostly. But operationally, it’s orphaned. Nobody wants to own it because understanding it requires reading through code written in a hurry to solve an immediate problem, with comments that made sense at the time but need context nobody documented.

This becomes critical when something needs to change. Your team wants to add a new ticket field to the sync. Or ServiceNow announces an API deprecation. Or the integration’s error rate slowly climbs and nobody’s sure why. Now you need someone to become the expert again, which means reading code, understanding the data flow, testing changes carefully because you’re not sure what might break.

The person who reluctantly takes this on does it because someone has to, not because they want to. They debug the issue, make the minimum change necessary, and hope they don’t have to touch it again. The integration accrues technical debt because nobody feels ownership, and refactoring something you don’t own feels risky.

This pattern repeats across every custom integration as teams grow and shift focus. The integrations that seemed like quick wins become maintenance liabilities that nobody wants to touch. You realize you’ve built a collection of single-purpose tools that only make sense to the people who built them, and those people have moved on.

The real cost of integration infrastructure

Custom integrations don’t exist in isolation. Each one needs infrastructure: error handling that actually tells you what went wrong, logging detailed enough for debugging, authentication that doesn’t involve API keys in a shared document, and monitoring that alerts someone before customers notice problems.

You can build all of this. The question is whether you want to build it for every integration, or whether you need that infrastructure to exist consistently regardless of which team builds what.

When your first custom integration fails silently for three days before someone notices, you add monitoring. When the second integration exposes credentials in logs, you add secret management. When the third integration crashes and you can’t figure out why, you add detailed logging. Each integration teaches you something about what infrastructure you needed before you built it.

Integration platforms provide this infrastructure by default. Centralized credential management, audit logs, error monitoring, and access controls exist for every integration. More importantly, they’re consistent. Every integration, regardless of which team created it, operates within the same control framework.

This consistency matters more as integration count grows. When you have three custom integrations, tribal knowledge suffices. When you have eight, you need systems that ensure integrations remain manageable even as the people who built them move on. The platform becomes the system that prevents integrations from becoming operational black boxes.

The infrastructure question becomes concrete when you calculate actual costs. Track time spent on each custom integration over a quarter: debugging, explaining how it works to new team members, updating it when APIs change, investigating why it stopped working. Include the opportunity cost—what isn’t your team building because they’re maintaining integrations?

Most teams underestimate this dramatically. They see three days to build, not the three hours per month maintaining it. Multiply that across six integrations and suddenly you’re spending multiple weeks per quarter on integration maintenance alone. That’s weeks not spent on improving your ITSM workflows or reducing ticket escalation friction.

When to move custom integrations to platforms

Clear triggers indicate when custom integrations should migrate to platforms.

The original builder is no longer available

Not just gone from the company—unavailable to maintain it. They’ve moved teams, shifted focus, or have enough other responsibilities that maintaining the integration feels like legacy work. When you notice reluctance to touch an integration because no one wants to own it, migration becomes worthwhile.

You’re building a second similar integration

If you’re about to build a connection to your project tracking tool after already building one to another system, both touching the same ITSM platform, pause. You’re about to create a pattern that will expand. Handle the integration infrastructure question now rather than after you have eight custom integrations with inconsistent error handling.

API providers announce version deprecation

Platform providers sunset API versions on schedules you can’t control. When you receive deprecation notices, every integration using that version needs updates. This is a natural migration moment. The integration needs work regardless—evaluate whether that work should be updating custom code or moving to a platform that handles version migrations for you.

Maintenance time exceeds platform costs

Calculate the quarterly cost: developer hours spent on debugging and updates, time explaining how integrations work, deployment complexity, documentation maintenance. When the quarterly cost exceeds what platform licensing would cost, migration makes financial sense even before considering reduced operational risk.

Migration trigger	What it looks like	Why it matters
Original builder unavailable	No one wants to touch the code; knowledge exists only in git history	Integration becomes operational black box
Building similar integrations	Second or third connection to same systems	Pattern about to multiply; infrastructure gaps will compound
API deprecation notices	Provider announces version sunset	Required work anyway; natural time to evaluate platforms
Maintenance cost exceeds licensing	Team spending 10+ hours per quarter per integration	Direct financial case for migration

The pattern: when you start spending more time maintaining integrations than they save, platform migration becomes operationally and financially justified.

When custom integration is still the right answer

Platform limitations are real. There are legitimate scenarios where custom integration remains the viable path.

Build custom when you’re integrating with internal systems that platforms don’t support. If you need to sync your service desk with a proprietary database or custom-built tool, you’re writing code regardless. Platform value depends on both ends having supported connectors.

Build custom when you need integration behavior that platforms fundamentally don’t support. Complex orchestration across three or more systems with conditional logic often exceeds what platforms can handle. If your integration needs to coordinate updates across multiple systems based on specific business rules, platform limitations become actual blockers.

Build custom when compliance requirements mandate specific data handling. Some regulated environments require data transformation logic to be auditable at the code level, or need integrations to run entirely within specific network boundaries. Platform architecture might not support these constraints.

Build custom when your transformation logic contains proprietary business rules that differentiate your service delivery. If the way you route and categorize incidents contains institutional knowledge that’s core to how you operate, that logic might need to stay under your control.

The key is being honest about which scenario you’re in. “We could build it” isn’t the same as “we should build it.” If your reasons for custom integration are primarily about initial cost rather than actual technical requirements that platforms can’t meet, you’re probably overbuilding.

Making the strategic decision

The build-versus-platform decision isn’t about integration capability. It’s about whether you want to maintain integration infrastructure as your integration count grows.

For most IT operations teams, integration infrastructure is necessary but not strategic. The business value is in having systems connected reliably so escalation context transfers smoothly and teams can collaborate across tools. The value isn’t in how that connection is implemented or who maintains the underlying infrastructure.

This suggests a default toward platforms for standard integration patterns—syncing tickets, updating statuses, maintaining field mappings across tools. Custom builds make sense when you have genuinely unique requirements that platforms can’t handle, or when you’re integrating with systems platforms don’t support.

The moment to evaluate this is before you build your fourth or fifth custom integration. By then, you have data about actual maintenance costs. You understand which integrations require ongoing attention and which mostly run themselves. You’ve experienced the pain of knowledge silos and the cost of context switching. You can make an informed decision about whether that pattern should continue.

If you’re at that evaluation point, or if you’re looking at existing custom integrations and wondering if there’s a better path forward, platforms like Unito handle the infrastructure concerns—API maintenance, error monitoring, access controls, bidirectional synchronization—so your team can focus on supporting operations rather than maintaining integration code. The integrations still need thoughtful configuration and ownership. But the operational burden shifts from “build and maintain everything” to “configure and monitor.” For teams already stretched thin, that shift often makes the difference between sustainable operations and constant firefighting.

View the full article