Systems integration that holds up on a bad day

What this actually solves

Somewhere in your company, a person is the integration. They export a list from one system on Monday morning, tidy it in a spreadsheet, and paste it into another. Every website enquiry arrives as an email that somebody retypes into the CRM. Every order gets keyed a second time into the accounts package. It works, in the sense that the numbers eventually arrive. It costs a salary, it is slower than anyone admits, and on the day that person is ill, nothing moves at all.

The second problem is quieter and more expensive. Two systems hold the same figures and the figures disagree. What the CRM says you sold is not what the accounts say you sold, and once that has happened twice, nobody trusts either report. Meetings stop being about what to do next and turn into arguments about which screen is right. The real product of an integration is not the saved minutes. It is having one answer.

What you are buying is a set of scenarios running on an integration platform — Make, Zapier or n8n, depending on what you already pay for and how much data moves — that carry records between your tools either on a schedule or the moment something happens. No bespoke software is written, so there is nothing unusual for anyone to maintain in two years. And the connecting itself is the easy part. Anyone can wire two apps together in an afternoon and watch a test record appear at the other end. The work is in what happens when the same person fills the form twice, when an API stops answering at four in the morning, and when the real export is vastly bigger than the file you tested on.

What we build, and in what order

1. Map it on paper before anything is wired. Which system is the source, which is the destination, exactly which fields travel, in which direction, and at what moment. This is also where we agree the source of truth field by field and get it confirmed in writing, because that one decision prevents most of the arguments that come later. Half a day to two days.
2. Write the field mapping sheet and decide the duplicate rule. Every source field against its destination field, the transformation it needs on the way, and what should happen when it arrives empty. Then the dedupe key — match on email first, fall back to phone, and when neither exists create the record but flag it as doubtful rather than pretending it is clean. Half a day to a day.
3. Build it one module at a time, running each before adding the next. Every place that would naively be a create becomes a search, then create or update, so a repeat submission cannot mint a second record. Building this way means that when something misbehaves there is exactly one suspect. Three days to several weeks, depending on how many systems and directions there are.
4. Put error handling on everything that can realistically fail. Each module gets a handler that decides between retry, ignore, alert and park, an alert that goes to a named person rather than a shared address nobody reads, and a place where failed records land marked as failed so they can be replayed. Half a day to two days.
5. Test the ugly cases, including a deliberately broken credential. The same person submitting twice in quick succession, an empty email, a phone number full of spaces and dashes, special characters in a name, a very long message — and then, crucially, a token changed to something invalid on purpose, to prove the error handler actually fires. A test plan that only proves the happy path proves nothing. One to three days.
6. Run it against real volume, then hand it over. Rate limits and pagination never appear in a small test and always appear on the first real day, so the scenario is exercised against a full-size dataset with the queuing and page-walking in place. You get a short document saying what it does, where it runs, which accounts it is connected to, and what to check first if records stop arriving. One day to a week.

Tools, so you know what you are getting rather than a black box. Make, Zapier or n8n for the scenarios themselves, Postman for probing an unfamiliar API before a single module is built, and Workato or Celigo where an existing enterprise agreement already dictates the platform. One rule we hold to throughout — when AI is used to draft a cleaning or migration script, it is given the structure of your file, the column names and formats, never your actual customer records. Names, emails and order histories do not leave the project.

What moves the price

The range is $1,500–$25,000 and the work runs 3–12 weeks. Where you land in both is decided by three things.

How many systems, and how many directions. A single one-way flow from a form into a CRM with a notification on the end is a small, quick piece of work. Four systems that all inform each other is not that same work multiplied out — every additional connection adds its own API, its own error codes and its own tests, and the combinations grow faster than the count.

How much data moves, and how quickly. A handful of records a day is a different engineering problem from thousands, because at volume the APIs start refusing you. Rate limits mean the scenario has to queue and back off rather than push, and pagination means a list has to be walked page by page instead of fetched in one go. Neither shows up in a demo, and both have to be built for from the start when the numbers are large.

What has to happen when it breaks. The cheapest version notifies someone and stops. The expensive version retries with a delay, parks what it cannot deliver, alerts a named owner, and lets the backlog be replayed once the other end recovers. That resilience is what separates the two ends of the range, and it is worth paying for exactly in proportion to how much it costs you when records go missing for a day.

What usually goes wrong

Two-way sync gets built because someone asked for it. It sounds obviously right — update either side and both stay current. In practice each system updates the other, the update echoes back, and records ping between them; or an older value in one overwrites a newer value in the other and nobody can say when it happened. Insist it starts in one direction, that which system owns each field is written down, and that the reverse path is only added once the first is proven.

Only the happy path is tested. You submit the form, the contact appears, everyone is pleased. In the real world the same person submits again next week, a plain create makes a second contact, and months later the CRM is full of near-identical records nobody can tell apart. Insist on search-before-create, on an agreed rule for what to match on, and on the duplicate case being tested specifically.

It fails silently and you are the last to know. With no handler on the module, an API that stops answering makes the scenario simply halt. It does not warn anyone. Days of leads go nowhere, the sales team assumes it has been a quiet week, and the first notification is an angry phone call. Every scenario needs a handler on every fallible step, an alert with a name attached, and something visible you can look at to confirm it ran today.