Integration & iPaaS

Most 'automation' pain is integration pain: the same customer exists in three systems, the invoice never arrives, the employee record is stale. We design integrations as products — contracts, mapping, retries, dead-letter queues, and observability — whether the runtime is an iPaaS you already pay for or a small service we run in your cloud.

We start from the business event, not from the vendor connector catalogue. Create-customer, update-leave-balance, post-invoice: each has a source of truth, a destination, and a failure policy. Transformations are tested. Secrets live in your vault. We avoid nightly full dumps when incremental or event-driven is viable, because full dumps hide drift until finance notices.

When an iPaaS is the right home we implement there and document promotion between environments. When the platform would become a second ERP, we recommend a service or a database-level pattern instead. Tool choice is a consequence of volume, team skill, and existing licences.

You get flows in production, a runbook for poison messages, and a map of what talks to what. The next developer should be able to add a field mapping without reverse-engineering a production job. We also document rate limits, retry budgets, and who is paged when a destination API starts returning 500s, so integration failure is an operations event with an owner rather than a silent backlog in a vendor log.