How to choose between a cloud integration platform and integrations written in code, with a decision table, the hidden costs on both sides and when a mix is the right answer.
In short
An iPaaS (integration platform as a service) is a cloud service with prebuilt connectors, visual workflows and central monitoring for connecting systems. Custom integrations are code your team writes against each system's API. Choose a platform for many standard flows between well-known systems; choose custom code for complex logic, high volumes or a product you sell. Most companies end up with both.
Every company with more than a handful of systems eventually faces the same question: should integrations live in a platform or in code? Vendors of both answer confidently, and in opposite directions. This comparison from Devies, a Gothenburg-based product and engineering consultancy, is for CIOs, IT managers and architects choosing how to connect ERP, CRM, e-commerce, finance and partner systems, and who need to justify the choice beyond the first project.
What is iPaaS, and what is a custom integration?
An iPaaS is a vendor-managed cloud platform for building, running and monitoring integrations between applications, data sources and partners, usually with low-code tools and a library of ready-made connectors. In Swedish it is often called an integrationsplattform. A custom integration is software your team or partner writes, hosts and maintains, calling each system's API directly.
A concrete example is Azure Logic Apps. Microsoft describes it as a cloud platform for automating workflows and integrating systems "with little or no code", with more than 1,400 prebuilt connectors, and with options to run inline code or call functions when a connector does not cover the need. Other well-known platforms include MuleSoft, Boomi and Workato.
A custom integration can be as small as a scheduled script or as large as an event-driven service with queues, retries and its own monitoring. What defines it is ownership: you decide the logic, the hosting and the release cycle.
How do a platform and custom integrations compare?
They differ most in speed for standard flows, control over complex logic, how cost grows with volume, and who you depend on. The decision table puts the options side by side.
Criterion
iPaaS
Custom integration
Mix
Speed to first flow
iPaaS
Fast when connectors exist
Custom integration
Slower, everything is built
Mix
Fast for standard flows
Complex business logic
iPaaS
Possible, but visual flows become hard to read
Custom integration
Natural fit, full control
Mix
Logic in code, plumbing in platform
Cost drivers
iPaaS
Licences, connectors and runs or messages
Custom integration
Developer time, hosting and maintenance
Mix
Both, but each used where cheapest
Cost at high volume
iPaaS
Can rise steeply with message-based pricing
Custom integration
Usually flatter per message
Mix
Volume-heavy flows in code
Monitoring and error handling
iPaaS
Built in and centralised
Custom integration
Must be built or added
Mix
Platform as the shared console
Skills needed
iPaaS
Integration specialists, some low-code users
Custom integration
Software engineers
Mix
Both
Version control and testing
iPaaS
Varies by platform; often weaker than code
Custom integration
Standard engineering practice
Mix
Mixed
Vendor dependence
iPaaS
High: flows live in the platform's format
Custom integration
Low for logic, still tied to the systems' APIs
Mix
Moderate
Typical fit
iPaaS
Many standard SaaS-to-SaaS and ERP flows
Custom integration
Core business logic, products, high volume
Mix
Most mid-sized companies
Neither option removes the hard part. Field ownership, matching rules and error handling must be designed either way, as our guide to CRM integration shows step by step.
What are the hidden costs on each side?
The hidden cost of iPaaS is lock-in and pricing that grows with usage; the hidden cost of custom code is maintenance that nobody budgeted for. Both are manageable if you plan for them.
iPaaS:
- Pricing per run, message or connector can make a cheap pilot expensive at full volume. Model your real message counts before you sign.
- Flows are stored in the platform's own format. Moving to another platform usually means rebuilding them.
- Visual flows with dozens of branches are hard to review, test and hand over.
Custom code:
- Every API change in a connected system becomes your problem. CRM and ERP vendors release often.
- Monitoring, alerting, retries and dashboards have to be built, and they are easy to skip.
- Knowledge concentrates in the developers who wrote the code unless documentation and reviews are in place.
Both:
- Messages can arrive twice. Microsoft states that Logic Apps delivers messages "at least once", so workflows must handle duplicates. The classic answer is the Idempotent Receiver pattern: a receiver that can safely process the same message several times. It applies equally to code.
When should you choose an iPaaS, and when custom integrations?
Choose a platform when you have many standard flows between well-known systems and want central monitoring; choose custom integrations when the integration carries core business logic, high volume or is part of a product you offer to others.
Choose iPaaS when:
- You connect common SaaS and ERP systems that already have maintained connectors.
- You have many small flows and a small development team.
- Central monitoring, alerting and access control matter more than fine-grained control.
- Business or IT staff should be able to adjust simple mappings without a release.
Choose custom integrations when:
- The logic is complex, such as pricing, allocation or reconciliation rules.
- Volumes are high or latency must be low, and per-message pricing would hurt.
- The integration is part of your product or a service you sell to partners.
- No connector exists, or the connector cannot express your rules.
Choose a mix when: you have both, which is most mid-sized companies. A common pattern is to run routine flows on the platform and put complex logic in small services that the platform calls, with one shared place to monitor everything.
Devies sees the custom side in its work as a certified Wolt integration partner for retailers. According to the page, Devies builds custom integrations that sync prices and inventory in real time and send orders automatically into retailers' existing POS or ERP systems, aimed at retailers with large product ranges and high order volumes. That is the kind of flow where volume, timing and retailer-specific logic favour code.
What should you decide before choosing?
Before choosing, decide which flows you need over the next two to three years, who will own and monitor them, and how much logic sits in them. The tool follows from those answers.
- List current and planned flows with expected message volumes.
- Mark each flow as standard plumbing or business logic.
- Check which systems have maintained connectors, and how deep they go.
- Decide who monitors integrations and fixes errors, and which skills they have.
- Ask platform vendors for pricing at your real volumes, and estimate maintenance hours for code.
- Plan an exit: how would you move flows if the platform or vendor changes?
Our guide to connecting ERP, CRM and finance describes the integration patterns that sit behind these choices.
Keep reading
From our work
Client Case: StadsbyggnadsförvaltningenHow Devies helped Gothenburg's city planning office turn fragmented traffic data into a living, trusted Traffic Catalogue.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is iPaaS?
iPaaS stands for integration platform as a service: a cloud platform, managed by a vendor, for building, running and monitoring integrations between applications, data sources and partners. It usually offers prebuilt connectors, visual workflow design and central error handling. Examples include Azure Logic Apps, MuleSoft, Boomi and Workato. In Swedish it is often called an integrationsplattform.
Is iPaaS cheaper than custom integrations?
It depends on the number of flows and the volume. For many small, standard flows an iPaaS is often cheaper because connectors and monitoring come ready-made. At high message volumes, usage-based pricing can exceed the cost of running code. Compare licence and run costs at your real volumes with development and maintenance hours for code over three years.
Can we combine an integration platform with custom code?
Yes, and most mid-sized companies do. A common pattern is to handle routine flows and monitoring on the platform and put complex business logic in small custom services that the platform calls. Platforms such as Azure Logic Apps support calling functions or running inline code for this purpose. The key is one shared place to monitor all flows.
How do we avoid lock-in with an iPaaS?
Keep business logic out of visual flows where possible, document every flow and its mappings outside the platform, and use standard formats and APIs at the edges. Check how flows can be exported and what a migration would involve before signing. Some lock-in is the price of convenience; the aim is to keep it at a level you can afford to undo.
