I spend most of my professional life connecting systems that were never designed to talk to each other. After doing this for years, I've landed on a framework for the build-vs-buy question that's worth sharing.

The Default Answer Is "Buy"

Engineers don't want to hear this. We love building things. But unless connecting System A to System B is your core business, you're almost always better off with an existing connector or middleware platform.

It's not about capability. Any decent engineer can build a REST integration. It's about maintenance. That custom integration works great on day one. On day 300, when the upstream API changes its auth flow or the downstream system adds a required field or volume jumps 10x... who's maintaining it? Usually the person who built it, because nobody else understands it.

When "Build" Is the Right Answer

There are exactly three scenarios where I say build custom:

  1. The integration IS the product. If this connection is what customers pay for, own every line.
  2. The data can't touch a middleman. Healthcare, financial services, anything with regulatory requirements that prohibit third-party processing.
  3. Nothing on the market can actually do it. Not "can't do it elegantly." Actually can't. This is rarer than people think.

The Hidden Third Option

What I recommend most often is a hybrid. Use a platform for the commodity stuff (HRIS to ATS, CRM to email) and build custom for the one or two integrations that are genuinely unique to your business.

This keeps engineers focused on differentiated work while the boring plumbing is someone else's problem. And it IS boring. Nobody should be hand-coding OAuth token refresh logic in 2026.

The Identity Layer Changes Everything

Here's what most integration conversations miss: identity. If your systems don't share a common understanding of "who is this user," every integration turns into a mapping exercise. Employee ID in HR, user principal name in the directory, email address in the ticketing system. You end up building translation tables and praying they stay in sync.

Get your identity layer right first. Centralize auth. Establish a single source of truth for user identity. Then integrations get dramatically simpler because the "who" question is already answered.

What I Tell Clients

When someone asks me to build an integration, I start with three questions:

  1. What happens if this goes down for 24 hours? (If the answer is "nothing critical," you might not need it.)
  2. Who maintains it after I leave? (If they can't name someone, we need a managed solution.)
  3. Does this already exist as a product? (90% of the time: yes.)

The best integration work I do isn't writing code. It's helping people realize they don't need custom code in the first place.