Every IT consultant eventually takes on an integration project that sounds simple on the phone: "we just need our CRM to talk to our invoicing tool." It sounds like a day of work. It's rarely a day of work — and the gap between how the project is described and how it actually goes is where a lot of consultants get burned, usually on their first few integration jobs before they learn to see it coming.
The technical problems (rate limits, schema mismatches, undocumented APIs) get talked about constantly. What gets talked about far less is the business and relationship side of integration work — the part that determines whether the project is actually profitable and whether the client relationship survives it. Here are five things nobody warns new IT consultants about before they take on their first small business integration project.
1. It's Never Just Connecting Two Systems
The request always sounds like a single connection: A talks to B. Once you're actually inside both systems, you usually find that A needs to talk to B, which turns out to already have an undocumented connection to C, which a former employee built to solve a problem nobody remembers, and B's data doesn't mean what you assumed it meant until you see how C is using it.
What looked like one integration is actually an audit of every system the business runs, whether anyone asked for that or not — because you can't safely connect two systems without understanding what else depends on them.
What this actually costs: a project that was scoped and quoted as "connect A to B" turning into something three or four times larger before you've written a single line of integration code.
2. Clients Don't Know What They Don't Know
Most small business owners describe their integration need in terms of the outcome they want — "I want new orders in QuickBooks automatically" — not in terms of the actual data flow, edge cases, or failure handling involved. That's a completely reasonable way for them to think about their own business. It's a completely unworkable starting point for a technical spec.
The hard part isn't the client being unhelpful. It's that a good discovery conversation has to ask questions the client has never had to think about — what happens to a duplicate order, what happens if a customer's address doesn't match, what happens if the sync runs while someone's mid-edit — and each answer usually reveals another undocumented business process that was living in someone's head, not in any system.
What this actually costs: a quote based on the client's description of the problem, followed by a much longer discovery phase once the real requirements surface — discovery that's easy to underprice if you haven't budgeted for it explicitly.
3. You Inherit Every System's Worst Day
Once an integration is live, it's the connective tissue between two (or more) systems the client depends on. When one of those systems has a bad day — an outage, an API change, a billing lapse that suspends the account — the integration is usually the first thing to visibly break, and the consultant who built it is usually the first call.
It doesn't matter that the outage was Salesforce's fault, or that the client's own team let a subscription lapse. From the client's perspective, "the sync stopped working" and "you built the sync" are the same sentence.
What this actually costs: getting blamed for, and expected to fix, problems that originate entirely outside the system you built — on a timeline the client experiences as an emergency regardless of whose fault it actually is.
4. Pricing an Integration Is a Moving Target
A fixed-bid quote assumes the scope is known at the time of the quote. Integration work routinely reveals its real scope only after you're inside the systems — which means the fixed bid that felt reasonable at the kickoff call can turn into underpriced work by the third week, through no error in the original estimate.
Charging hourly solves the estimate problem but creates a trust problem: clients get uneasy watching the hours climb on something that was described to them as "just connecting two systems." Neither pricing model resolves the core issue on its own — the mismatch between how simple the request sounds and how unpredictable the actual scope is.
What helps: pricing discovery and integration as separate phases, with the discovery phase explicitly used to produce a real scope and a real quote for the second phase — instead of guessing at both in the same conversation.
5. No One Owns the Integration Once It's Built
An integration isn't a one-time deliverable the way a website or a report is. It's a piece of infrastructure that depends on two or more external systems continuing to behave the way they did on the day it was built. When one of those systems changes an API, deprecates a field, or updates its data format, the integration doesn't announce that it's now wrong — it just quietly starts producing bad data, or stops working entirely, on a timeline nobody controls.
If there's no arrangement for ongoing maintenance, the integration becomes an orphan: something that worked at delivery, with no one responsible for noticing when it stops.
What this actually costs: a client who assumes "done" means "done forever," and a consultant who gets an unhappy call eight months later about a problem that had actually been silently accumulating for weeks.
The Underlying Pattern
None of these five problems are really about integration code. They're about the space between what an integration project sounds like when it's requested and what it actually is once you're inside it: a scope that expands on contact, a client who doesn't yet know what they need, a piece of infrastructure that inherits every dependency's failures, a price that's hard to fix in advance, and a system that needs a long-term owner it usually doesn't get.
The consultants who do well with this kind of work aren't the ones who write the fastest integration. They're the ones who set expectations about scope, ownership, and maintenance before the first API call is ever made — because by the time those conversations happen naturally, they're usually happening during a crisis instead of a kickoff call.
About the Author
I'm Alex Susanu, an IT Consultant focused on helping businesses and professionals navigate technology and solve real-world IT challenges.
🌐 Learn more about my work: https://alexsusanu.com/
Top comments (0)