Connecting two applications is rarely the whole problem
An integration demo may show information moving successfully from one system to another. A real business process must also cope with missing records, delayed responses, duplicate messages, conflicting data and unexpected changes.
That is why a simple-looking integration can become a substantial software engineering project.
What commonly creates complexity?
Different definitions of the same information
One platform may treat a customer as a billing account while another treats each site as a customer. Mapping those structures requires business decisions, not simply technical code.
No clear source of truth
When two systems can update the same field, the organisation must decide which record prevails and how disagreements are handled.
Conditional business processes
The integration may need to understand contractual rules, approvals, exceptions or calculations before it can take the correct action.
API and vendor limitations
External applications may impose rate limits, restricted fields, differing authentication methods or no reliable webhook support. Suppliers can also change their interfaces.
Errors and retries
What happens when a transaction partly succeeds? Reliable systems need error records, notifications, safe retries and reconciliation instead of silent data loss.
Security and access
Integrations may have access to important business data. Credentials, least-privilege access, logging, retention and safe deployments all need attention.
When an off-the-shelf connector is enough
If the process is common, the data models align and a proven connector meets reliability requirements, bespoke development may not be needed. Start there.
When custom development is justified
A tailored integration can be valuable where the process involves unusual transformations, approvals, proprietary rules, multiple external parties or a need for specialised monitoring and error recovery.
Define the business outcome first
Instead of beginning with ‘connect A to B’, describe what should happen from start to finish: who initiates the process, what records change, how errors are handled and how the organisation knows it worked.
Ask how the integration will be maintained
Document interfaces, failure handling, dependencies and monitoring. An integration that works on launch but cannot be diagnosed later creates a new business risk.
Practical next step
A technical discovery should identify systems, supported interfaces, records, workflow rules, exception handling and acceptance tests before a formal estimate is finalised.
