The easy part and the real part
Connecting two systems is, on the day it is demonstrated, easy. One side sends a record, the other side receives it, everyone nods. Most integrations that go wrong looked exactly like that in the meeting.
The real work is in the cases nobody demonstrates:
- The other end is down for an afternoon. Does the data wait and retry, or is it lost?
- The same event arrives twice. Webhooks do this. Does the customer get charged, emailed or invoiced twice?
- Half a write succeeds. The order saved but the payment record did not. Which system is now right?
- Somebody edits the record in both places. Which change wins, and does anybody find out?
- The supplier changes their API. Does it fail loudly on the day, or quietly for a month?
Done properly, retries, queues and reconciliation handle all of that, and nobody notices the integration exists. That is the goal. You should only hear about it when it has something to tell you.
What gets connected
The usual candidates are the systems that hold money and customers:
- Accounting, so invoices and payments raised in one place appear in the books without retyping
- Payment providers, including the refunds, part payments and failed payments that the happy path skips
- CRMs, so sales and operations are looking at the same customer
- Email and notifications, triggered by what actually happened rather than by someone remembering
- Imports and exports at the edges, CSV included, because a lot of the world still runs on files
We do not publish a list of products we have "integrated with", because it would be a list of logos rather than a promise. If a system has a documented API, it can be connected; if it only has a file export, that can be scheduled and checked. What we look at in the scope is how that API behaves when things go wrong, because that decides the price.
Contracts, not assumptions
Every boundary we build has a typed contract: a precise definition of what goes across it and in what shape. On Fortium, the platform for an accountancy practice, the API underneath the staff dashboard, client portal and extraction services is typed end to end, so the frontends cannot drift from it. On the construction and M&E platform, single sign-on lets staff move between eight applications without noticing a boundary.
The same discipline applies to a third-party system. Incoming data is checked against what it should look like before it touches your database, and anything that does not fit is held and reported rather than half-saved.
Your data should stay yours
An integration is also a question of who holds the truth. The construction group now has an owned component catalogue behind its own API, rather than data it merely had access to through somebody else's product. Curbed has CSV import and export at every boundary, because fleets already have their data somewhere and will want it back.
That is worth asking about any integration: if you stopped paying for one of these products tomorrow, would you still have your records? Who owns the code covers the same question for the software itself.
When a connector will do
Many products now ship with ready-made connections to each other, and there are general automation tools that link them for a monthly fee. For a simple, low-stakes flow, such as a form submission landing in a spreadsheet, use those. They are cheaper than anything we would build.
Custom integration earns its place when money moves, when the volume is high enough that failures matter, or when the logic in between is specific to how you work. Fixed price, off a written scope, with engagements from £4,000.