Stuart Totterdell
Technical Director
Anyone who has sat through a polished demo of two SaaS products being wired together can be forgiven for thinking integration is a weekend job. You pick a trigger, map a few fields, run the test, and green ticks start appearing. It looks simple because, at that moment, it is.
That is the demo. It is not what production looks like.
Production starts the day an identical record turns up twice in the destination system. It starts when a supplier quietly changes a product code list and forgets to mention it. It starts when someone runs a manual correction halfway through a scheduled sync, or when your nightly job collides with month-end close because nobody thought to coordinate the calendars. At that point, what you have is not really an integration. It is a small distributed system with data contracts, failure modes, and human beings moving through the middle of it.
What a weekend build usually contains
One happy path. One account. A small set of fields. And a developer who happens to know to look in the logs when something feels off.
That is a useful prototype. It is not an integration layer, and pretending it is creates most of the trouble that follows.
What production integration actually contains
The list below is the one people skip because it sounds dry. It is also the list that separates "we connected the systems" from "the business can run on them."
Idempotency, so that the same event arriving twice does not create the same effect twice. Retries with sensible backoff, because transient failures are normal and throwing a tantrum in the logs is not a recovery strategy. Some form of ordering guarantee, because "the most recent version wins" is often the wrong rule. Reconciliation, because the two systems will eventually disagree, and the business needs a pre-agreed way of resolving that rather than a panic email at 17:55 on a Friday. Monitoring that tells you a sync failed before finance does. And access control, because integrations are, by nature, privilege escalations waiting for an opportunity.
None of that is glamorous. All of it is the difference between a connected system and one you can confidently run the business on, which is why serious data and systems integration work is less about moving data and more about making two organisations' worth of unspoken assumptions survive contact with real load.
Schema drift is not a rare event
Vendors ship updates. Finance restructures a chart of accounts. Sales quietly adds a new field that means something subtly different from an existing field with a similar name. An ERP consultant fixes something your integration was relying on as a happy side effect of a bug.
If your integration is a script with no contract tests and no alerting on shape changes, you do not find out about drift when it happens. You find out when a downstream report starts producing numbers that are plausible but wrong.
The handover gap
Internal teams sometimes treat integrations the way they treat features - build it, ship it, move to the next sprint. Integrations behave more like infrastructure. They need an owner who considers change management part of the product, not an overhead bolted onto it later.
If that owner does not exist internally, keeping the work in-house has not saved money. It has concentrated risk in a place that does not have the capacity to absorb it when something goes wrong.
This is where an independent tech consultancy view tends to pay for itself, not by replacing the internal team, but by forcing explicit contracts, proper test discipline, and operational defaults that the business otherwise has no incentive to slow down for.
When a weekend really is enough
To be clear, this is not a counsel of despair.
A narrow, low-stakes, one-way sync with a small dataset and a single consuming team can genuinely be a short build. It is fine. The only requirement is that everyone involved agrees, up front, that this is what it is - a small convenience - and nobody later starts treating it as foundational.
When a weekend is not enough
Multi-team consumers. Regulated data. Financial totals. Anything that has to be auditable. Anything that triggers behaviour on the customer side. None of those are a weekend. They are development and build work with an integration spine, and they deserve the same seriousness as any other system the business depends on.
The one-sentence version
If losing the integration for forty-eight hours would be a real problem for the business, it was never a weekend project. It was a production system that was shipped without production standards, and that gap will find a way to make itself visible sooner or later.
If a business is already in that position, the answer is not regret. It is to write down the real risks, reduce the blast radius where possible, and bring the integration up to a standard that matches what is now depending on it - whether that work happens internally or with external help, as long as the requirement is on operability rather than enthusiasm.
