Integration platform or custom code? Compare the work after the first failure

The connector works in the demonstration. A customer moves from the CRM into the finance system, and the workflow turns green. For the enterprise architect choosing between an integration platform and custom code, the more revealing demonstration starts when the finance system accepts the request but its response never arrives.

Should the integration retry? Could it create a second customer or invoice? Can an operator establish what happened without editing production data by hand? Those questions expose the operating work behind the interface, whichever implementation approach is chosen.

An integration platform as a service, or iPaaS, can supply connectors, workflow execution and administrative tools. Custom development offers control over the implementation, but the team must provide or assemble those capabilities. The sensible comparison uses one complete integration and the people who will maintain it.

Put the uncertain delivery in the evaluation

Take a hypothetical workflow that transfers an approved CRM deal to a finance system and requests an invoice. The receiving system creates the invoice, but the integration times out before receiving confirmation. While the failed item is waiting, the source API changes a field used in the customer mapping.

A blind retry risks repeating the business action. A blanket rule against retries risks abandoning work that never reached the destination. The design needs a way to distinguish an uncompleted request from a completed request whose acknowledgement was lost.

Where the destination supports it, a stable operation identifier can let repeated requests be recognised as the same intended action. Otherwise the integration may need a reconciliation step or a controlled exception queue. The architect should establish the destination’s actual behaviour, including concurrent requests, before approving a duplicate-prevention claim.

Azure Logic Apps documentation shows why default behaviour belongs in that review. Supported triggers and actions can resend requests after timeouts or specified error responses. Most supporting operations use an exponential default policy with up to four retries, while some operations use a different default. “The platform handles retries” therefore leaves an essential business question unanswered: are these retries safe for this operation?

Ask the platform proposal to identify the exact connector operation, policy and exception path. Ask the custom-code proposal to show the equivalent behaviour and tests. Both should demonstrate how an operator finds an uncertain invoice, establishes its destination state and resumes processing without duplicating the effect.

Managed execution does not remove design choices

The alternatives are not limited to a visual platform or a server running hand-built scripts. A custom integration can use managed orchestration while retaining custom mappings and business logic.

AWS Step Functions, for example, distinguishes Standard workflows from Express workflows. Standard supports long-running workflows and an exactly-once execution model unless retry behaviour is specified. Asynchronous Express uses at-least-once execution; Synchronous Express uses at-most-once execution. Express workflows have a five-minute maximum duration.

These are documented execution semantics, not interchangeable promises about the final business outcome. An integration team still has to consider its configured retries, external API effects and recovery path. A workflow type that fits rapid event processing may be unsuitable for a process waiting hours for a human exception decision.

The same documentation describes different billing units: state transitions for Standard, and executions, duration and memory for Express. This makes the expected failure and retry workload relevant to a cost model, alongside the normal transaction volume.

Compare retained responsibilities

Operating requirement	Platform proposal must show	Custom proposal must show
Authentication changes	Who renews connections and handles revoked permissions.	Who maintains credential use, rotation and access configuration.
Schema change	How incompatible mappings are detected, versioned and deployed.	Contract tests, mapping changes and a supported deployment route.
Uncertain delivery	Connector-specific retry behaviour and an operator recovery path.	Duplicate handling, reconciliation and controlled replay.
Production support	Evidence available when a run fails and the limits of supplier support.	Logs, ownership, on-call coverage and maintenance capacity.
Exit	What configuration, history and mappings can be exported and reused.	What depends on selected runtimes, libraries and specialist knowledge.

Use this comparison to expose work rather than assign an automatic winner. A well-supported connector can remove recurring maintenance. A connector that lacks a required operation may force awkward workarounds that are harder to own than a small, explicit service.

Equally, custom code is not automatically portable. Its business logic may depend on a particular runtime, message service, data model or engineer’s knowledge. Ask another team member to diagnose a representative failure using the proposed documentation and access, rather than accepting that the original developer can fix it.

Price change and recovery as part of the service

Compare initial implementation, platform and infrastructure charges, testing, support effort and expected change work over the same period. Include non-production environments and the evidence retention needed for investigations. Keep uncertain maintenance estimates visible instead of burying them inside a precise total.

In the fictional CRM-to-finance workflow, the acceptance test should combine the lost acknowledgement with the field change. Can the team preserve the original intent, identify rejected records, repair the mapping and complete the correct invoices? A clean rerun of an entirely fresh batch would avoid the difficult question.

Choose the implementation the operating team can support through those changes. Before approving it, make the API inventory, ownership and dependencies explicit. That is the information both a platform configuration and a custom service will need when the next connection fails.