There are five real options — not two. Build in-house if your team knows the API and has bandwidth. Use an embedded iPaaS (Paragon, Merge) for speed at the cost of ownership. Outsource to a specialist for complex builds with full code handoff. Publish connectors on Make, Zapier, or n8n to let your customers self-serve simpler automations. Or mix approaches based on what each integration actually requires.
Your sales team just lost another deal. The prospect loved the product but needed a Salesforce integration you don't have. Your CTO says the team can build it — in about six weeks. But six weeks means six weeks off the product roadmap. And the next prospect will need SAP.
This is the moment every B2B SaaS company hits. You need integrations to win deals, but building them pulls your best engineers off the work that makes your product better. So what are the actual options?
There are five paths. Each one fits a different situation, and each one has trade-offs that most "build vs buy" articles conveniently skip.
Option 1: Build in-house
You assign your own engineers to build the integration.
When this is the right call:
Your team already has engineers who know the target system's API. They've worked with SAP's OData endpoints, or NetSuite's SuiteTalk REST API, or Salesforce's composite resources before. They understand the auth flows, the pagination quirks, the rate limits. They're not learning — they're executing.
You plan to maintain the integration long-term as a core part of your product. This isn't a one-off — it's infrastructure your product depends on, and you want full institutional knowledge in-house.
You have the engineering bandwidth. Your product roadmap can absorb 4–8 weeks of one or two engineers working on integration instead of features.
When it goes wrong:
Enterprise APIs are not like the APIs your team uses every day. SAP's OData pagination behaves differently across modules. NetSuite requires OAuth 2.0 client credentials with token refresh and aggressive rate limit backoff. D365's OData endpoints return inconsistent error formats depending on which service you're hitting.
Teams that haven't worked with these specific APIs consistently underestimate the timeline. What looks like a two-week project becomes six weeks once you account for sandbox provisioning (which alone can take weeks and cost thousands), authentication edge cases, data mapping complexity, and the error handling that only surfaces when real customer data flows through.
Every week your engineers spend on integration plumbing is a week they're not shipping product features. That opportunity cost is real and compounds over time.
Realistic cost: EUR 8,000–30,000+ per integration when you factor in engineer salary, benefits, and opportunity cost. Timeline: 4–8 weeks for a team's first enterprise integration; faster for subsequent ones if the same engineers stay on the project.
Option 2: Embedded iPaaS platforms
You subscribe to a platform like Paragon, Merge, Workato, or Prismatic that provides pre-built connectors and embed them into your product.
When this is the right call:
You need to offer many integrations fast — say, 10+ systems within a few weeks — and the platforms already have connectors for the systems your customers use. Your integrations are relatively standard. You're syncing contacts, pulling invoices, updating records — not building complex multi-step workflows with custom business logic. You're okay with a managed runtime.
When it goes wrong:
You're renting, not owning. Your integrations run on their servers, using their code, under their billing model. If Paragon or Merge raises prices, changes their API, deprecates a connector, or goes down — your integrations go with them. There's no code to export. No fallback.
Customization has a ceiling. These platforms handle standard CRUD operations well. But when customer #15 needs a custom field mapping that the platform doesn't support, or you need multi-step approval logic, or you need to handle a vendor-specific API quirk — you hit workarounds that might defeat the purpose.
Pricing grows with your customer base. What starts as a reasonable monthly fee becomes significant at scale.
If you're building MCP servers for AI agent interactions, most embedded iPaaS platforms aren't designed for this. They were built for webhook-and-API integration patterns, not MCP's bidirectional, agent-driven model.
Realistic cost: EUR 500–5,000/month depending on platform and usage, growing with your customer count. Over 2–3 years, total cost often exceeds what a custom build would have cost — and you still don't own the code.
Option 3: Outsource to a specialist team
You hire an integration engineering team to build the integration for you. They deliver the code, you own it.
When this is the right call:
Enterprise APIs aren't your team's core competency, and you don't want them to become it. You'd rather have someone who's already built 20 SAP integrations handle the edge cases, while your team stays on the product roadmap.
You need production-ready fast. A specialist who has sandbox environments, pre-built patterns for common enterprise systems, and experience with the specific auth flows and data models can deliver in 1–2 weeks what would take your team 4–8 weeks.
You want to own the code. Unlike embedded iPaaS platforms, a good specialist delivers full source code. No subscription, no vendor lock-in, no dependency on a third party's infrastructure.
When it goes wrong:
You pick the wrong team. A generalist development agency that's "done some API work" is not the same as a team that specializes in enterprise integration. If they're learning SAP's OData API on your dime, you'll pay more and wait longer than building in-house.
Knowledge transfer matters. After delivery, your team needs to maintain it. Good specialist teams deliver comprehensive documentation, runbooks, and data flow diagrams. Bad ones hand over code and disappear.
Realistic cost: EUR 3,000–15,000 per integration depending on system complexity and scope. Timeline: 1–2 weeks with an experienced team. You own everything after handoff.
Option 4: Publish connectors on automation platforms
Instead of building direct integrations, you publish your app as a connector on Make, Zapier, or n8n. Your customers then build their own automations.
When this is the right call:
Your customers already use automation platforms. Your integration needs are mostly data syncing, notifications, and simple automations. You want your product listed in a marketplace — it's a distribution channel and product at the same time.
When it goes wrong:
You don't control the integration logic. Your customers build their own workflows, which means they can build them badly. When something breaks, they'll contact your support team, not Make's or Zapier's.
The connector itself needs maintenance. Each platform has its own connector format, certification process, and quirks. If you publish on all three, that's three separate codebases.
Certification can be a bottleneck. Make and Zapier both review connectors before listing them publicly — revision cycles can take weeks.
Enterprise customers rarely accept this approach. Telling a large company to "use our Zapier connector" won't fly. They need direct, auditable integrations.
Realistic cost: EUR 3,000–10,000 to develop and certify a connector per platform, plus ongoing maintenance.
Option 5: Build a hybrid approach
Most mature B2B SaaS companies don't pick just one path. They combine approaches based on what each integration requires.
Use platform connectors (Make, Zapier, n8n) for self-serve automations. Use embedded iPaaS for standard product integrations where speed matters more than customization. Use specialist teams for complex enterprise integrations where the API is difficult and you need full code ownership. Build in-house only when the integration is core to your competitive advantage. Use specialist teams for MCP servers when your AI agents need enterprise data access.
The decision framework
Answer these six questions. They'll point you to the right option.
- Does your team have deep experience with the target system's API?
- Yes → Consider building in-house
- No → Outsource or use a platform
- Is this integration for your product, or for your customers to self-serve?
- For your product → Options 1, 2, or 3
- For your customers to wire up themselves → Publish connectors on Make/Zapier/n8n
- Is this a one-time build or do you need 10+ integrations?
- One-time, complex → Outsource to a specialist
- Many standard integrations → Consider embedded iPaaS
- Many complex integrations → Outsource, build patterns, then bring some in-house
- How important is code ownership?
- Critical → Build in-house or outsource
- Flexible → Embedded iPaaS or connectors
- What's your timeline?
- This quarter → Outsource or embedded iPaaS
- This year → Any option works
- Yesterday → Outsource to someone with sandbox environments ready to go
- Does this involve AI agents or MCP?
- Yes → Build in-house (if you have MCP expertise) or outsource to an MCP specialist
- No → All five options are viable
The comparison table
| Build in-house | Embedded iPaaS | Specialist team | Platform connectors | Hybrid | |
|---|---|---|---|---|---|
| Timeline | 4–8 weeks (first build) | Days to weeks | 1–2 weeks | 2–6 weeks per platform | Varies |
| Cost per integration | EUR 8K–30K+ (salary + opportunity) | EUR 500–5K/mo (ongoing) | EUR 3K–15K (one-time) | EUR 3K–10K per platform | Mixed |
| Code ownership | Full | None — you rent | Full | You own connector; customers own workflows | Depends |
| Customization | Unlimited | Limited to platform | Unlimited | Limited to SDK | Best of all |
| Maintenance | Your team | Platform (in subscription) | Your team (with docs) | You maintain connector | Split |
| Vendor dependency | None | High | None | Moderate | Partial |
| Best for | Core product integrations with known APIs | Breadth of standard integrations fast | Complex enterprise systems | Self-serve automations for SMB/mid-market | Mature teams with diverse needs |
| MCP-ready | If team has MCP expertise | Most don't support MCP yet | If specialist has MCP expertise | No | Yes, with right specialist |
What we see teams get wrong
After building integrations, MCP servers, and platform connectors for B2B SaaS companies, here are the patterns that lead to regret:
Underestimating enterprise API complexity. "It's just a REST API" is the sentence that precedes every blown timeline. SAP, NetSuite, and D365 are not Stripe. Budget 2–3x whatever your initial estimate is if it's your first time.
Choosing embedded iPaaS for complex integrations. Platforms like Paragon and Merge are genuinely good for standard use cases. But when you need custom data transformations or multi-step business logic, you'll spend more time working around limitations than building properly.
Publishing connectors and calling it an integration strategy. Having your app on Make and Zapier is great for distribution. But when a prospect asks "do you integrate with SAP?" and you say "yes, through Zapier" — that's not the answer they're looking for.
Choosing the cheapest freelancer. Enterprise integration is not a commodity. A freelancer who charges EUR 30/hour and has never touched NetSuite's SuiteTalk API will cost you more in the long run than a specialist team at 3x the rate.
Not planning for maintenance. Every integration needs ongoing attention. APIs change, schemas evolve, rate limits shift. If documentation isn't part of the deliverable, it's not done.
FAQ
Should I build integrations in-house or outsource?
It depends on three factors: whether your team has experience with the target system's API, how much engineering bandwidth you can spare from the product roadmap, and how critical code ownership is. If your team knows the API and has bandwidth, build in-house. If not, outsource to a specialist for speed and ownership, or use an embedded iPaaS for simpler integrations where speed matters more than customization.
How much does it cost to build an enterprise integration?
In-house: EUR 8,000–30,000+ per integration. Embedded iPaaS: EUR 500–5,000/month ongoing. Specialist team: EUR 3,000–15,000 one-time. Platform connectors: EUR 3,000–10,000 per platform. The right comparison isn't just upfront cost — it's total cost over 2–3 years including maintenance, platform fees, and opportunity cost.
What's wrong with using iPaaS?
Nothing — for the right use case. The trade-off is vendor dependency: you don't own the code, customization is limited, and pricing grows with your customer base. For standard integrations where speed matters most, they're a solid choice. For complex enterprise integrations or MCP server development, you'll likely need a custom approach.
Should I publish connectors on Make, Zapier, or n8n?
If your customers already use automation platforms and your needs are primarily simple workflows, then yes. It's also a distribution channel. But connectors aren't a substitute for direct enterprise integrations. Most B2B SaaS companies need both: connectors for self-serve customers, and direct integrations or MCP servers for enterprise accounts.
How long does an enterprise integration take to build?
In-house with experienced engineers: 2–4 weeks. In-house without target API experience: 4–8 weeks. Specialist team: 1–2 weeks. Embedded iPaaS: days to weeks for setup, but ongoing dependency. The biggest variable isn't the code — it's sandbox access, auth setup, and edge case handling.
Can I start with an embedded iPaaS and switch to custom later?
Yes, but it's not a smooth transition. Embedded iPaaS platforms don't export code. When you switch, you're building from scratch — not migrating. Some teams use this approach intentionally: start with Paragon or Merge to validate demand, then rebuild critical integrations as custom code once they've proven which ones matter most.
What if I need MCP servers, traditional integrations, and connectors?
Many B2B SaaS companies need all three — MCP servers for AI agent features, traditional API integrations for core product functionality, and platform connectors for self-serve customer automations. Using one team for all three avoids duplication and ensures the integration architecture is consistent. At Inovaflow, this is exactly what we do.