Build vs Buy: When to Use an iPaaS and When to Write Custom Code

When a business needs to connect two systems, one of the first decisions is how to build the integration. Use an iPaaS like Celigo or Workato? Write custom code against the APIs? Use a middleware layer? Pay for a pre-built connector?

We get asked this question constantly, and the honest answer is that it depends. But it depends on specific, practical things — not vague hand-waving about "it depends on your requirements." Here's how we actually think through the decision.

When an iPaaS is the right call

Integration platforms like Celigo and Workato exist because most integrations follow predictable patterns. You're syncing orders from A to B. You're keeping inventory consistent across systems. You're pushing customer data from a CRM to an ERP. The data shapes are known, the APIs are documented, and the transformation logic is straightforward.

For these scenarios, an iPaaS saves you enormous amounts of time. The platform handles authentication, connection management, error handling, retry logic, logging, and monitoring. You focus on the business logic — field mappings, transformation rules, and workflow sequencing — rather than building infrastructure from scratch.

We'd recommend an iPaaS when: you're connecting well-known SaaS applications with documented APIs, your data transformation is standard mapping and formatting, you need built-in monitoring and error management, your team needs to maintain the integration without deep developer involvement, and you want to move fast — weeks instead of months.

The sweet spot for iPaaS is the mid-market. You've outgrown Zapier-style point-and-click tools, but you don't have the engineering team to build and maintain custom integration infrastructure.

When custom code makes more sense

Sometimes an iPaaS adds overhead without adding value. If you're integrating two internal systems with non-standard APIs, or building a highly specialised data pipeline with complex business logic, custom code gives you more control and fewer constraints.

We'd lean towards custom code when: the source or destination system has a poorly documented or non-standard API that doesn't have an iPaaS connector, the integration requires complex data processing — aggregations, joins across multiple data sources, or conditional logic that's awkward to express in a visual mapping tool, you're building a real-time event-driven integration where milliseconds matter, your engineering team is strong and already has deployment, monitoring, and alerting infrastructure in place, or the integration is a core part of your product rather than an operational workflow.

A common example: we've worked with businesses that need to aggregate data from multiple warehouse locations, apply complex allocation logic based on customer tier and product availability, and then push a calculated result to the ERP. That kind of multi-step computation is painful to build in most iPaaS visual editors. A Python script or Node.js service handles it cleanly.

The hybrid approach

In practice, most businesses end up with a mix. And that's fine — as long as it's intentional rather than accidental.

A pattern we see working well: use an iPaaS for your standard data sync flows (orders, inventory, customers, financials) and custom code for the edge cases that don't fit neatly into the platform's model. The iPaaS handles 80% of your integration needs with lower maintenance overhead. Custom code handles the 20% that requires specialised logic.

The key is being deliberate about which approach you use for each integration. What we see go wrong is businesses that start with custom code for everything, end up with a tangle of scripts that nobody fully understands, and then try to migrate to an iPaaS — or vice versa, businesses that try to force everything through an iPaaS and end up with flows so complex they're harder to maintain than code would be.

The maintenance question

This is where the decision often becomes clear. Building an integration is one thing. Maintaining it for three years is another.

iPaaS platforms handle a lot of maintenance automatically — API version changes, authentication token refreshes, connection health monitoring, and error alerting. When something breaks, the platform gives you a dashboard showing exactly what failed and why.

Custom code requires you to build and maintain all of that yourself. Logging, monitoring, alerting, error handling, retry logic, credential management — it's not hard to build, but it's easy to neglect. We've inherited custom integrations where the original developer left the company and nobody knows how the scripts work. The code has no tests, no documentation, and the error handling is a try-catch that swallows exceptions.

If your team will maintain the integration long-term and has the discipline to keep it documented and monitored, custom code works fine. If the integration will be handed off to a non-developer team, an iPaaS is almost always the better choice.

Cost comparison

The cost equation isn't as straightforward as comparing iPaaS subscription fees to developer hours.

An iPaaS subscription runs between $500 and $5,000 per month depending on the platform and volume. Setup costs for a typical integration project run between $10,000 and $40,000. Ongoing maintenance is relatively low — the platform handles the infrastructure.

Custom code has no subscription fee, but the build cost is usually higher — $20,000 to $80,000 for a comparable integration, because you're building the infrastructure as well as the business logic. Ongoing maintenance costs are harder to predict and often higher than expected, especially when things break at inconvenient times.

For most mid-market businesses, iPaaS is more cost-effective over a three-year horizon. For larger enterprises with dedicated integration engineering teams, custom code can be cheaper — but only if the team is properly resourced.

Our recommendation

Start with an iPaaS for anything that fits the platform's model. Order sync, inventory sync, customer data, financial data — these are solved problems and there's no value in reinventing the wheel.

Reserve custom code for integrations where the iPaaS genuinely constrains you — complex logic, non-standard APIs, real-time requirements, or specialised data processing.

And whatever you choose, invest in monitoring and documentation from day one. The integration that works silently and reliably is the one you barely notice. The one that fails silently and nobody understands is the one that ruins your weekend.

If you're weighing up the options for a specific integration project, we're happy to give you an honest assessment. Sometimes we'll tell you an iPaaS is the right call. Sometimes we'll recommend custom code. The answer depends on your situation, not on what we prefer to sell.