iPaaS or custom code: choosing an integration approach

The question usually arrives framed as a choice between an integration platform and writing code, as though one of them is the serious option and the other is a shortcut. Both are legitimate engineering choices. Which one fits depends on transaction volume, how much the logic branches, what happens when a run fails, and who has to keep it working two years from now. We build both. On an anonymized trades services engagement we put Make.com at the center of a bridge stack on purpose, because the binding constraint was a renewal date rather than an architectural preference. This page is about telling those situations apart before you commit.

What each approach actually is

A low-code integration platform (iPaaS, workflow automation, whatever the category is called this year) gives you a hosted runtime, a visual builder, and a catalog of prebuilt connectors. You authenticate to each system once, drag steps into a sequence, and the vendor handles hosting, scheduling, and connector maintenance. Pricing is typically metered per operation, task, or run.

Custom integration code is a service you own: a repository, a deployment pipeline, and code that calls vendor APIs directly or through their SDKs. You are responsible for hosting, scheduling, retries, monitoring, and the maintenance burden when an upstream API changes. In exchange you get the full toolset of ordinary software engineering: branching, code review, automated tests, structured logs, and the ability to move the whole thing somewhere else.

The honest difference is not capability. Nearly anything you can express in code can eventually be expressed on a low-code platform. The difference is what each one costs you as complexity and volume grow, and how legible the result stays to the next person.

Where low-code genuinely wins

Teams that dismiss low-code on principle end up spending engineering weeks on problems that were worth two afternoons. These are the cases where it is straightforwardly the correct call.

• Speed to first value. A working connection between two systems with published APIs is a same-week outcome, sometimes a same-day one. No pipeline, no hosting decision, no on-call rotation.
• Business-user ownership. An operations manager can change a notification trigger or add a field to a sync without filing a ticket. That is a real organizational capability, not a compromise.
• Low and predictable volume. At a few thousand operations a month, metered pricing is cheaper than the engineering time it would take to replace it, and it stays cheaper for years.
• Simple, stable mappings. Field A goes to field B. When the transformation is close to a direct copy, code adds ceremony without adding safety.
• Interim bridges. When a deadline is fixed and the target architecture is not yet known, a low-code stack buys observation time. Our trades engagement did exactly this ahead of an ERP renewal.
• Validating a workflow before you commit. Building the cheap version first is often the fastest way to learn what the real requirements are.

Where low-code breaks down

Pricing that scales with transactions

Metered per-operation pricing is the most common reason teams migrate off. A scenario with a dozen steps consumes a dozen operations per record. At a hundred records a day that is invisible. At fifty thousand records a day it is a line item someone in finance asks about, and the cost tracks transaction count rather than the business value of the integration. Do the arithmetic at three times your current volume before you build anything load-bearing.

Branching logic that stops being readable

Visual builders handle linear flows well. They handle conditionals adequately. They handle a flow with nine branches, three nested iterators, and error paths that rejoin the main sequence very badly, not because the platform cannot execute it, but because no human can look at the canvas and say what it does. Code has the same complexity problem, but it has functions, names, and tests as a defense. A canvas does not.

No real version control or review

Most platforms offer some form of revision history. Almost none offer a meaningful diff, a branch, or a pull request. You cannot review a proposed change before it goes live, you cannot see who changed what and why, and rollback is a restore rather than a revert. When a scenario runs a financial process, the absence of code review is a control gap, not just an inconvenience.

Testing

The usual testing approach on a low-code platform is to run the scenario and look at what happened. That works until the interesting cases are the rare ones: the duplicate record, the partial failure halfway through a multi-system write, the record that arrives with a null where the mapping assumed a value. Those cases are cheap to write as automated tests against code and expensive to reproduce by hand on a canvas.

Debugging a failure from three weeks ago

This is the failure mode that surprises people. Execution logs are usually retained for a limited window and are scoped to a single run. When someone reports that invoices stopped syncing sometime last month, you want to query structured logs across a date range, correlate by record ID, and replay the affected records. Reconstructing that from a run history you can only page through is slow, and sometimes the data is simply gone.

Portability

Scenarios do not export into anything another platform can run. The logic, the mappings, and the accumulated edge-case handling live in a proprietary format. Migrating means rebuilding, and the rebuild is usually harder than the original because nobody documented why step fourteen exists. That risk is acceptable for a notification workflow and a poor bet for the process that moves your revenue.

The dimensions that actually decide it

The hybrid pattern most mature setups land on

Organizations that have been doing this for a while rarely standardize on one approach. They split the work by consequence and volume. The high-volume, financially consequential paths (order to invoice, inventory to fulfillment, payroll) run as owned code with tests, monitoring, and reconciliation. The long tail of notifications, internal alerts, spreadsheet exports, form intake, and one-off syncs stays on the low-code platform where the operations team can change it without a release.

What makes the hybrid work is a written rule about which side a new integration starts on, and a review that revisits it. Without the rule, every integration goes to whichever team hears about it first, and you end up with the billing sync on a canvas and a Slack notification service running in Kubernetes.

1. 1

   Write down the split. A simple threshold works: anything touching money, anything above a stated volume, or anything with more than one conditional branch is built as code.

2. 2

   Give every integration a named owner, regardless of which side it lives on. Unowned automations are how a business ends up depending on a scenario nobody can explain.

3. 3

   Monitor both the same way. Failures from the low-code platform should raise the same alert, in the same place, as failures from your own services.

4. 4

   Review the inventory twice a year against volume and incident history, and promote the ones that have crossed the line.

Signals you have outgrown low-code

None of these are fatal on their own. Two or three together on the same integration mean the cheaper option has stopped being cheaper.

• The platform bill has become a budget conversation, and it grows with transaction volume rather than with headcount or revenue.
• Only one person understands the critical scenario, and changes wait for that person's availability.
• You have started duplicating scenarios instead of parameterizing them, because branching in place became unmanageable.
• A change went live without review and broke something in production.
• You are being asked to explain a failure from a period that has already dropped out of log retention.
• Recovery from a partial failure involves someone manually re-running records from a spreadsheet.
• The integration now enforces business rules that exist nowhere else, and nothing tests them.

How to choose without relitigating it every quarter

Decide with numbers rather than preference. Estimate the operation count at three times current volume and price it. Count the conditional branches; more than two or three is a signal. Ask what happens if this integration silently stops for a day. If the answer involves customers or money, it needs tests, alerting, and reconciliation, which is easier to build in code than around a canvas. Then check who is expected to maintain it, because building an engineering-owned service for a workflow the operations team changes weekly creates a bottleneck you will resent.

If the answers are genuinely ambiguous, start low-code. It is the reversible choice. You will learn the real edge cases in production for a fraction of the cost, and if you do end up rewriting it in code, you will be rewriting against a known specification instead of a guess.