Build vs Buy: My Integration Nightmare from 400+ Self-Developed Integrations to Sanity

This time the article is pretty techy, let’s say, and it’s all about how to choose the right iPaaS for your SaaS. But before we dive into frameworks and comparisons, let me tell you a story.

The Day Integration Became My Personal Hell

I remember it vividly. Every. Single. Day. Another notification. Another API change. Another integration breaking. When we were running my company, LeadsBridge, we had built 400+ integrations in-house. And you know what? It was a fucking nightmare.

Every morning started the same way: open email, see notification from some platform changing their API, realize we need to update our integration. Again. One integration if we were lucky. Sometimes more. And this wasn’t a one-time thing. This was our life.

We needed the right contacts. We needed partnerships established. We needed… everything. And at some point, we ended up maintaining only the top integrations. The rest? Almost outdated. Some even deprecated. We couldn’t keep up.

That’s when I learned the hard way: there’s a massive difference between build and buy when it comes to integrations.

The Three Paths (And Why They All Kinda Suck)

So whenever you enter the integration space — or marketplace, or however you want to call it — you face this challenge. Your SaaS needs to connect with something else. Why? Because nowadays, companies of any size are using multiple platforms. They’re always disconnected. And from the user perspective, they would love to see them connected.

If you’re a product manager, you know this question all too well: Do we want to build or do we want to buy?

Let me break down what I learned.

Path #1: Build In-House (AKA The Control Freak’s Dream)

Building in-house is good when you don’t have a clear idea yet. Maybe something is very custom. Maybe you just need that first integration to understand the problem space.

The upside? You have everything in control. You can customize exactly the UI you want.

The downside? Holy shit, the maintenance costs. They’re hidden at first, but when you scale? They’ll eat you alive. Trust me, I lived this nightmare.

And here’s the thing nobody tells you: when you maintain integrations in-house, you’re basically signing up to be in a relationship with every single platform’s API team. Forever. Good luck with that.

Path #2: Partner-Built Integrations (AKA The Hope and Prayer Strategy)

Partner-built sounds great on paper. You maintain the SDK, the framework, the guidance. Then it’s up to the partners to build.

But here’s the reality: you need a very strong partnership team. And even then, especially when you’re not the biggest fish in the ocean, it becomes this never-ending game of “who will build this fucking integration?”

“Will it be your team or our team?”

This conversation repeats over and over for months. If not years. And then — after the partner finally commits — you get the message: “Hey, you know what? We changed our priority. We’re not integrating anymore.”

Why? Because integration is never seen as part of the core offering. It’s always secondary.

You don’t have the control. You don’t control who’s committed. You don’t control the experience. You don’t control the insights, the performance, the optimization timeline. Nothing.

And if you’re a PM like me who wants to drive adoption and retention? You want that control.

Path #3: The Third-Party Solution (AKA Please Someone Else Deal With This)

This is where iPaaS comes in. And let me tell you, I recently evaluated more than 30 options. Thirty. And I believe they can be summarized in a few key buckets.

The iPaaS Landscape: What Actually Exists Out There

Bucket #1: Common API Layer (e.g. Merge, Finch API)

These platforms give you a single API layer. They handle authentication, custom fields, everything that’s modeled — it’s up to them.

The beauty? Integration is stupid simple. Typically a single endpoint. You just pass a different slug to identify information. Done.

The issues? Most don’t offer on-premise installation. They might only have a single data center. And here’s the big one: it’s very hard to influence their roadmap. You can’t create your own custom connector. You can only request. Then it’s up to them to prioritize.

Plus, if a category isn’t important to them, they’ll never build it. And typically, they don’t let you white-label the authentication widget. From the user perspective, you don’t have control. It’s up to them.

Bucket #2: Workflow-Based iPaaS (e.g. Zapier, Workato, Tray)

These are ideal for complex workflows. Very complex. Very hardcore. And with AI, they’re becoming less technical.

The good news? You can create custom connectors and complex automation.

The reality check? You won’t need an engineer, but you will need an automation engineer. Someone familiar with field mapping and data manipulation. They call it low-code, no-code, but it’s still code. Let’s be honest.

And even for basic use cases, you need a workflow. Then you replicate that workflow for every customer. Each connector handles data differently, so you’re doing a lot of field mapping. A lot.

Plus — and this is critical — their costs are unpredictable. Most are usage-based. You don’t know usage when you start. When you scale, the bills skyrocket.

Bucket #3: Action-Based or Agent-Like iPaaS (e.g. Refold AI, Paragon, Membrane)

These are emerging now. Rather than workflows, they offer unified actions or endpoints. Very compatible with agentic chat experiences.

Perfect for: Manual, non-repetitive tasks. Conversational integrations.

Let’s imagine: “I need to retrieve information from my Salesforce.” Connect your Salesforce. Boom. Done. No more than this.

The problem? Gen AI is not deterministic. Sometimes it works. For a very similar use case, maybe it doesn’t. They don’t always have clear structure.

And again — usage-based pricing. I remember when Salesforce launched Agent Force. The pricing was impossible to estimate. Something like $2 per interaction in the last 24 hours for the same topic. Impossible.

Bucket #4: The Unique Approach (Membrane)

This category is pretty limited but unique. They model any integration using concepts like data sources and common actions: find by ID, list them, search, etc. They handle the complexity behind the scenes.

Ideal for: Low-level API-based integration. You can create a fully white-labeled experience.

Possible downsides? Sometimes they have many integrations, but not all are accurate. You’ll end up with support tickets asking them to fix something specific.

But — and this is important — they still handle the maintenance. You just need patience.

The Service Question Nobody Asks

Here’s something applicable to all categories: Do you want your team to own the service, or do you want their team?

Some iPaaS platforms offer professional services. This is very useful if you have budget. You don’t need a team. You only need to write good requirements, and they implement for you.

It’s a way to multiply your team without the complexity of hiring. You only need budget.

The Truth About Build vs. Buy

So what’s the answer? Which path is right?

Here’s what I learned after years of pain, 400+ custom integrations, and evaluating 30+ iPaaS solutions:

There is no perfect choice.

They’re all good. They’re all bad. Your use case is unique.

But what I want you to take away is this: huge thanks to all the founders who created these amazing iPaaS experiences. Because they found a way to help us as product leaders stay focused on our core value — which includes integration — without the complexity of managing each one individually.

That’s their focus. That’s where they should excel. And honestly? That’s what saves people like me from another 400-integration nightmare.

One Final Warning

Because AI is constantly evolving, this article might be outdated soon. Some platforms have already added new functionality since I started writing this months ago. MCP is now a thing, and many iPaaS providers are switching to or adding that functionality.

The landscape changes fast. But the fundamental question remains: Do you want to build your own integration hell, or do you want someone else to manage it for you?

I know my answer. What’s yours?

---

The Complete iPaaS Landscape (As of 2025-2026)

As I said, this is my biased and opinionated view of my story, but there are way more things. Way more iPaaSes and they are constantly evolving. Let’s say so, here is the list in an unordered way, and thanks for all the iPaaSes that anyway they give me the chance to test and to try.

• Refold AI
• Merge
• Finch API
• Paragon
• Membrane
• Zapier
• Workato
• Tray.io
• Boomi
• MuleSoft Anypoint Platform
• Celigo
• Jitterbit
• SnapLogic
• Informatica Intelligent Data Management Cloud
• Oracle Integration Cloud
• Microsoft Azure Logic Apps
• SAP Integration Suite
• IBM App Connect
• Software AG webMethods.io
• TIBCO
• AWS AppFlow
• Albato
• DBSync
• Frends
• Apideck
• Composio
• K2View
• Pandium
• …and counting