ON THIS PAGE · 4 SECTIONS▾
"Can we just connect it to the CRM?" It sounds like a small request, and the first version often is small. Most modern tools have an API, and pulling contacts from one system into another can be done in a day or two. The estimate is honest. It is also incomplete, because it prices the build and ignores everything that comes after.
An integration is not a feature you ship and forget. It is a dependency on another system you don't control, and it will need attention for as long as it runs. Teams that don't price that in end up, a year or two later, spending a surprising share of their engineering time keeping old connections alive.
01#Where the cost actually goes
Upkeep you don't choose
The other system changes on its own schedule. APIs get new versions and old ones are retired. Fields are renamed, rate limits are tightened, authentication moves to a new method. Each change is small, and each one arrives with a deadline you didn't set. An integration that worked untouched for a year can suddenly need a week of work because a vendor decided to retire an endpoint.
Multiply that by the number of integrations you run and the picture changes. Five connections, each needing a few days of unplanned work a year, quietly consume weeks of capacity.
Failures that are hard to see
When a screen breaks, someone notices. When an integration fails, it often fails silently: a sync stops, a webhook is dropped, a record is skipped because one field was in an unexpected format. Nothing looks wrong until someone downstream asks why a customer never received their confirmation, or why the numbers in two systems don't match.
Diagnosing these failures is slow because the problem sits between two systems, and each side's logs only tell half the story. The fix may take ten minutes. Finding it can take a day.
Data that drifts
Two systems holding the same information will disagree eventually. A contact is updated in one place and not the other. A record is deleted on one side and lives on in the other. Someone edits a value by hand to fix an urgent problem and the sync overwrites it the next morning. Every integration needs an answer to the question "which system is right?", and that answer has to be enforced in code, not just agreed in a meeting.
Knowledge that leaves
The person who built an integration knows its quirks: why it retries three times, why it skips records without an email, why it runs at two in the morning. When they move on, that knowledge often goes with them. The next person to touch it has to reverse-engineer the decisions before they can change anything safely.
02#Questions to ask before adding one
None of this means integrations are bad. Connected systems save real time and remove whole categories of error. It means each one should earn its place. Before agreeing to build, ask:
- How often does the data actually need to move? If the honest answer is weekly, a scheduled export and import may be enough, and far simpler to keep running.
- Is there already a connection that does this? Many tools offer built-in connectors that the vendor maintains for you. Using one shifts the upkeep to someone whose job it is.
- Could a person do this step in five minutes? For low volumes, a short manual step with a checklist can be cheaper over a few years than an integration that needs maintaining.
- Which system owns the truth? If nobody can answer this clearly, the integration will create disagreements faster than it resolves them.
- Who will own it in a year? If there is no obvious name, that is a cost too.
03#If you build it, build it to be kept
When an integration is the right answer, a few habits make the difference between one that needs constant attention and one that runs quietly.
Give it a named owner
One person or team is responsible for each connection: they receive its alerts, track the vendor's change notices and approve changes to it. Shared ownership in practice means no ownership.
Watch it, and watch for silence
Alert on failures, but also on absence. "No records synced in six hours" catches the quiet failures that error alerts miss. A simple daily count on each side, compared automatically, catches drift before a customer does.
Make failures recoverable
Assume every call can fail. Store what you intended to send before sending it, retry with a delay, and keep a record of anything that still fails so it can be replayed once the problem is fixed. This one design choice turns most integration incidents from lost data into a short delay.
Isolate it
Keep each integration's code in one place, behind a small interface, so a change in the other system means changing one module rather than hunting through the codebase. When the vendor ships a new API version, the work is contained.
Write down the decisions
Why it runs when it does, which system wins in a conflict, what it deliberately ignores. A few lines in a decision log save the next owner days of investigation.
04#Pricing it honestly
When you estimate an integration, give two numbers: the build, and the yearly upkeep. A reasonable starting assumption is that keeping a connection healthy will take a meaningful fraction of its original build effort every year, more if the other system changes often or the data is messy. Then add an allowance for incidents, because there will be some.
The build is a one-off. The integration is for as long as it runs.
Seen this way, some integrations are clearly worth it, some are better replaced by a weekly export, and a few shouldn't be built at all. All three are good outcomes. The bad outcome is the one nobody priced.