Answer
The math usually shifts once a business has more than two or three integrations in production. Custom code for a single connection can be fast to build and easy to reason about, but each additional custom integration tends to reinvent authentication, logging, error handling, and retry logic slightly differently, which means a team is eventually maintaining several one-off systems instead of one shared capability. That maintenance burden compounds especially fast when the people who wrote the original custom code move on, since IBM i integration skills are not always easy to backfill quickly.
A helpful exercise before deciding is to estimate how many integrations the business expects to need over the next two to three years, not just the one in front of them right now, and to be honest about how much internal capacity exists to maintain custom code long term. If the answer points toward an ongoing integration capability rather than a single interface, a platform's shared governance, monitoring, and reusable connectors usually pay for themselves. Running a small proof of concept with a real workflow on both approaches, rather than deciding from a feature comparison sheet alone, is the most reliable way to see which one actually fits the team.