iPaaS or custom integration? A decision framework, not a preference
Published 7 April 2026Updated 19 August 20269 min read
Use an iPaaS when the mapping is simple, volumes are modest, and the platform's failure behaviour is acceptable. Build custom when you need field-level conflict rules, audit trails, transactional guarantees, per-event cost economics at volume, or logic that outlives the connector's roadmap. The decision is driven by volume, auditability, and failure cost, not by ideology.
Where iPaaS genuinely wins
- Low-volume, low-consequence automations: notifications, form-to-CRM handoffs, file drops.
- Work that needs to exist this week and can be replaced later.
- Flows a business team should own and edit without an engineering release.
Where iPaaS quietly becomes expensive
Per-task pricing scales linearly with volume while custom engineering is largely fixed cost, so there is a crossover point. It usually arrives sooner than expected because retries, polling, and fan-out all consume tasks.
The subtler cost is failure behaviour. Most platforms retry a step, not a transaction. When step three of five fails, you are left with a half-applied change and no compensating action — the class of defect that produces double invoices and duplicate records.
Signals that you need custom engineering
- Two systems both author the same data and you need declared ownership per field.
- An auditor, regulator, or finance team will ask why a value changed.
- You need idempotency keys, transactional boundaries, or compensating actions.
- Throughput is high enough that per-task pricing exceeds a build budget within a year.
- The logic encodes competitive advantage and should not live in a vendor's flow editor.
The hybrid that usually wins
Keep low-stakes glue on an iPaaS where business teams can own it, and build the two or three flows that carry money, entitlement, or compliance risk properly. Deciding per flow rather than per organisation gets the best economics.
Frequently asked questions
Is Zapier or Make enough for business-critical integrations?
For notifications and simple handoffs, yes. For anything where a half-applied change costs money — invoicing, entitlement, inventory — the lack of transactional guarantees and compensating actions makes them the wrong tool.
At what volume does custom integration become cheaper than iPaaS?
It depends on per-task pricing and retry behaviour, but organisations commonly cross over in the low hundreds of thousands of monthly tasks. Model it with retries and polling included, because those dominate real usage.
Can we start on an iPaaS and migrate to custom later?
Yes, and it is often the right sequence. Keep the mapping documented and the data model clean so the migration is a re-implementation of known behaviour rather than a discovery exercise.
What a custom software integration actually costs — and why estimates vary so much
The cost drivers behind integration projects: object count, sync direction, data quality, auth model, volume, compliance, and the discovery work that prevents overruns.
Freshworks CRM integration: architecture patterns that hold up in production
A practical engineering guide to integrating Freshworks CRM with databases, products, billing, and warehouses: API surfaces, auth, rate limits, sync direction, conflict resolution, and audit.
Legacy modernisation without a big-bang rewrite
Applying the strangler-fig pattern to legacy business systems: seams, anti-corruption layers, dual-write and dual-read phases, data migration, and safe cutover.