When to Use an Integration Platform vs Building Direct
Know when maintenance costs make platforms cheaper than custom builds.
The average enterprise now runs 897 applications, up 6.4% year-over-year according to MuleSoft's 2024 numbers. Even mid-market companies are catching up fast: 118 SaaS apps per company in 2026, an 11% jump from the year before, and every one of those apps is a potential integration point. That means the build-versus-buy question isn't philosophy, since it's really arithmetic.
Building one or two direct integrations yourself is fine. Five or more, and the coordination cost of juggling separate codebases starts to compound. Ten or more, and the maintenance burden alone (roughly 8 to 12 hours of engineering time per integration per year) starts eating a real chunk of your team's calendar. The rest of this piece runs on three observable conditions: how many connections you need, how often they change, and what your team actually does well. These are conditions you can count, not vibes or preference.
What it actually costs to build and maintain a direct integration over time
Here's the number most engineers forget to budget for: it's not the build, it's everything after the build.
A moderately complex API integration runs $10,000 to $50,000 to construct. Push into advanced territory, real-time bidirectional sync, the kind of thing that keeps two systems perfectly mirrored at all times, and costs can clear $150,000. That's the sticker price, and nobody argues with it.
Maintenance shows up next, uninvited, every year, forever. Annual upkeep runs 15 to 25% of the original build cost. Take a $30,000 integration: that's $4,500 to $7,500 a year, just to keep it breathing. Multiply that by ten integrations, because nobody stops at one, and suddenly it's $45,000 to $75,000 a year in maintenance, before anyone asks for a new feature.
Run the tape forward two years and ten in-house integrations land somewhere between $500,000 and $873,000 in total cost, once everything gets counted. "Everything" is doing a lot of work in that sentence, because the costs that don't make it into the original estimate are exactly the ones that pile up quietly:
- Data transformation and field-mapping logic that nobody scoped properly the first time
- Security audits and compliance certifications that show up whether you invited them or not
- Downtime and rework when some upstream vendor changes their API without asking permission
- Documentation that rots the moment the engineer who wrote it takes a new job
Add those up and you're typically looking at 20 to 35% on top of the initial budget. Connect to an old, undocumented internal system (the kind held together with duct tape and one engineer's institutional memory) and tack on another 30 to 50% surcharge for the privilege.
The asymmetry is the whole story here. Build cost is visible: it's a line item, it's in the budget, someone signed off on it. Maintenance cost, by contrast, is diffuse, hiding in sprint velocity, in "why is this taking so long," in the slow erosion of a roadmap nobody notices until the quarter's over.
Where integration platforms genuinely earn their cost
Integration platforms sell one core promise: pre-built connectors, automatic patch handling, and monitoring that already exists so you don't build it from scratch. That promise collapses deployment time from months to days, and it's not a marketing line, it's a mechanical result of not reinventing plumbing that's already been built a thousand times before.
Custom integrations typically take 3 to 6 months to build. Complex enterprise ones can drag past two years, which is roughly the same amount of time it takes to forget why you started the project. iPaaS platforms, by contrast, can go live in hours or days, because the connector already exists and someone else already debugged it.
Platforms clearly win under a few conditions: five or more third-party SaaS connections, especially where a connector's already built and waiting; standard B2B workflows, CRM sync, data enrichment, outreach automation, ticketing, the stuff that's been solved a thousand times over and packaged into a dropdown menu; and teams where marketing, sales, or ops need to wire up an integration without waiting three sprints for an engineer to get to it.
Speed matters here too. Over 66% of businesses now want real-time integration, and platforms handle that at scale without anyone hand-rolling custom queueing logic. Gartner projects 70% of new applications will use low-code by 2026, which is the citizen-developer effect in action: business users self-serve the plumbing, engineers get their time back for work that actually differentiates the company.
Security rides along for free, too. SOC 2, GDPR, automatic patching, all handled by the vendor instead of becoming a recurring line on someone's sprint board. The correct way to think about integration middleware is that it's infrastructure, not a competitive edge, and buying infrastructure instead of building it is almost always the right call. Nobody wins a market by having the best custom-built webhook retry logic.
Where building direct still makes sense
Custom builds aren't the villain here. They're just not the default, and there's a real difference between "sometimes correct" and "usually correct."
Connecting internal systems to each other (your own databases, your own microservices talking amongst themselves) is a clean case for building direct. Routing that traffic through a third-party platform adds a hop that's slower, pricier, and solves a problem you don't have.
Sub-second latency needs or very high data volume push most platforms outside their comfort zone; they're built for moderate throughput, not for pipelines where every millisecond counts. Genuinely proprietary transformation logic, the kind that encodes real business rules no connector on the market supports, also belongs in a direct build. So does anything sitting inside a regulatory environment where data sovereignty rules block routing information through third-party cloud infrastructure, and finance and healthcare run into this constantly.
Then there's the scale reversal, which catches people off guard. Per-account pricing works fine when connection counts are small, then bends the economics backward once volume gets large. One fintech company supporting 1,200 QuickBooks connections hit hundreds of thousands of dollars a year in platform fees, more than it would've cost to build and maintain those same connections in-house. At that point the platform isn't saving money, it's charging rent on your own infrastructure.
The honest test is whether the integration encodes your competitive advantage, or whether it's plumbing. If it's plumbing, the platform wins nearly every time. And if it's a one-time, single-endpoint connection with zero expected change, building a clean, well-documented direct call can beat the overhead of learning a whole platform just to run one pipe.
How vendor lock-in and pricing models introduce risk on the platform side
Lock-in isn't a side effect of iPaaS platforms; it's baked into how most of them work. Proprietary transformation tools, custom workflow builders, platform-specific connectors, all of it means switching vendors later isn't a migration, it's a rebuild.
Per-account pricing is the sharpest risk at scale. It looks harmless at ten connections and turns into a real cost driver at a thousand, the same trap that caught that fintech at hundreds of thousands of dollars a year. Data sovereignty adds another wrinkle: routing sensitive data through a third-party cloud layer can conflict with governance rules in regulated industries, and that constraint rarely gets raised during the sales demo.
Before signing anything, ask a few pointed questions. What does pricing look like at 10 times current connection volume? Are transformation rules portable if the vendor relationship ends? Where does data actually sit and travel during a sync, and what happens to existing integrations if the vendor gets acquired or quietly sunsets a connector?
That last question isn't hypothetical. Salesforce's $8 billion acquisition of Informatica in May 2025 is a clear reminder that platform capabilities and pricing can shift hard, and fast, once a bigger company owns the wheel.
A decision framework organized around the three conditions that actually drive the choice
Three conditions decide this, not preference, not brand loyalty, not which sales rep bought lunch.
How many connections you need. One or two, stable and well-documented, and a direct build holds up fine. Three or four, and it's worth checking whether pre-built connectors already exist and how fast requirements are shifting. Five or more, and a platform almost always wins on total cost of ownership; maintenance burden at that scale is the deciding factor, full stop.
How often they change. Stable, infrequent change means a custom build amortizes well over time and maintenance stays cheap. Frequent change, upstream API versioning, schema shifts, new workflow demands, means a platform's automatic updates absorb cost that would otherwise land squarely on engineering's plate. Limited internal expertise shows up as a top integration barrier for 44% of firms, and change frequency multiplies that risk fast if there's no platform catching the fallout.
What your team's core competency actually is. Every hour an engineer spends patching an integration is an hour not spent on the product that makes the business money. If integration isn't the product, it shouldn't consume senior engineering time. Build is warranted when the logic is genuinely proprietary or governance rules block third-party routing, but those conditions need confirming, not assuming.
A quick gut check, five questions, no philosophy required:
- Does a pre-built connector already exist for this? Platform.
- Is the logic proprietary or compliance-restricted? Build.
- Is connection count about to grow a lot? Platform, but audit the pricing model at scale first.
- Is this two internal systems talking to each other? Direct call, skip the platform entirely.
- Does per-account platform cost at projected scale beat build-and-maintain? Build.
The honest limit of all this is that the right call at five connections might be the wrong call at fifty. Revisit the decision whenever connection count doubles, or whenever a major API change triggers a maintenance spike nobody saw coming, because the math doesn't stay still, so the decision shouldn't either.
