Ask an engineering team to build a feature and you will get an estimate that is roughly wrong in the ordinary way. Ask them to connect your system to somebody else’s and you will get an estimate that is wrong in a different and much worse way, because most of the unknowns are on the other side of a boundary they cannot see.
Why the estimates break down here specifically
The best evidence on this is not about integrations directly, but it explains the shape. Flyvbjerg and colleagues analysed 5,392 IT projects and found that cost overruns follow a power-law distribution: a large number of projects with small overruns, and a fat tail of projects with extreme ones.
Integrations concentrate the conditions that put a project in that tail. The unknowns are not in your requirements, where you can go and resolve them. They are in somebody else’s system, discovered one at a time, at whatever pace that organisation replies to email.
The four things that actually cost the money
You control one end
In a build, if the data model is awkward you change it. In an integration, the other side’s model is a given, including the field that means three different things depending on another field, and the identifier that is not actually unique.
Worse, it moves. The other side ships changes on their calendar, and you find out when something breaks. Ask who tells you about breaking changes, how far ahead, and whether there is a versioning policy before you sign anything.
The documentation is wrong in small, expensive ways
Not wholesale wrong. Wrong in the specific places that cost days: a field documented as optional that is required in practice, a date format that differs by endpoint, pagination that behaves differently past page 50, a rate limit that is lower than published, a sandbox that does not match production.
None of this is discoverable by reading. It is discoverable by calling, which is why the estimate has to come after the first real call rather than before.
Failure is the normal case, not the exception
Over a year, a network between two systems will be unavailable, slow, and occasionally worst of all: it will accept your request and time out before telling you whether it worked.
So you need idempotency, so a retry does not double the order. Ordering, because messages arrive out of sequence. Partial-failure handling, because three of five records wrote. Backoff, so your retries do not become the outage. This is the bulk of the engineering, and it is invisible in a demo where everything is up.
Nobody owns the mapping
Your “customer” and their “account” are not the same thing. Your status values and theirs overlap imperfectly. Somebody has to decide what maps to what, including the cases where the honest answer is that it does not.
That person is usually neither team, because it is a business decision wearing a technical costume. Name them before the build, or the mapping gets decided by whichever developer hit it first, at 4pm, and nobody finds out until the numbers disagree.
Where the effort actually goes
Reconciliation is the actual deliverable
This is the part most often missing from scope, and the part that determines whether anyone trusts the integration in year two.
Data flowing is not the same as data agreeing. Over months, two systems drift: a record was created during an outage, a retry double-wrote, someone edited one side directly, a delete on one side never propagated. None of these announce themselves. They are discovered when a total does not match and somebody spends a fortnight finding out why.
A reconciliation process is a scheduled comparison of both sides against agreed keys, producing a report of differences that a named person reads and acts on. It is unglamorous, it is usually cut when the budget tightens, and it is the difference between an integration you can rely on and one everybody quietly works around.
A cheaper version of the same idea, if the budget genuinely will not stretch: a daily count comparison on the two or three figures that matter, emailed to someone. Not a full reconciliation, but it turns silent drift into a visible number, which is most of the value for a fraction of the work.
How to get an estimate worth having
- Get credentials for the other system before you ask for a price. This is the single highest-leverage thing you can do, and it is usually the longest lead item, because it involves a third party’s procurement rather than engineering.
- Have someone make one real call against the real API, with real data, in a non-production environment. Ninety minutes of this changes the estimate more than a week of reading.
- Ask the four questions. Is there a test environment, does it have representative data, what is the rate limit, and who notifies you of breaking changes. Any “no” is a cost.
- Get the mapping decided by the business, not deferred to development. Field by field for the contested ones.
- Scope reconciliation explicitly, so it is a line someone chooses to cut rather than one that quietly never existed.
- Plan for the tail. Given the distribution, an integration budget with no contingency is not an estimate, it is a hope. Contingency belongs on the integration line specifically, not smeared across the project.
A supplier who quotes an integration confidently without having called the API is either guessing or padding, and you cannot tell which. Neither is good for you. The right answer to “how much to integrate with X” is “let us spend a day finding out, then tell you”, and a supplier offering that is being straight with you rather than being evasive.
The part that does not end
Integrations break on somebody else’s release schedule. A field is deprecated, an authentication method is retired, a rate limit tightens, a partner is acquired and migrates platforms. None of that appears in your roadmap, and all of it arrives as urgent work.
So budget for it as ongoing rather than as a project with an end date, which is the same lesson as what software maintenance really costs after launch. Monitoring that alerts on schema drift and error-rate changes is what converts these from incidents into tickets.
Related: why software projects run over budget covers the general case, writing a brief that gets accurate quotes covers getting integrations into the brief where they belong, and migrate, rebuild, or wrap covers the case where the other system is one of yours.
We estimate integrations after making a real call, not before, and we scope reconciliation as a deliverable. If you have two systems that need to agree and a quote you are not sure about, tell us what you are connecting.
Common questions
Why do software integration projects cost more than expected?
Because you control one end and not the other. The other system’s data model, quirks and release schedule are given to you rather than chosen, its documentation is wrong in specific expensive places that only a real call reveals, failure handling for retries and partial writes is most of the engineering and is invisible in a demo, and nobody has decided how one system’s fields map to the other’s. The working call made in week one, which is what the estimate was built from, is the smallest part of the job.
How do you estimate an integration project accurately?
Get credentials and make one real call against the real API before anyone quotes. Ninety minutes of that changes the number more than a week of reading documentation. Then establish whether a test environment exists and has representative data, what the actual rate limit is, and who notifies you of breaking changes. A supplier quoting confidently without having called the API is guessing or padding, and you cannot tell which.
What is reconciliation and why does it matter?
A scheduled comparison of both systems against agreed keys, producing a report of differences for a named person to act on. It matters because data flowing is not the same as data agreeing: over months two systems drift through outages, double-writes, direct edits and deletes that never propagated, and none of it announces itself. Reconciliation is usually the first thing cut from scope and is the difference between an integration people rely on and one they work around.
Do IT project cost overruns follow a normal distribution?
No. Research covering 5,392 IT projects found overruns follow a power-law distribution: most projects overrun modestly, but there is a fat tail of extreme cases. The practical consequence is that planning against an average badly understates the chance of a severe overrun, and integration work sits in the tail because its unknowns are inside a system you do not control.
Sources
- Bent Flyvbjerg, Alexander Budzier, Jong Seok Lee, Mark Keil, Daniel Lunn and Dirk W. Bester, The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution, Journal of Management Information Systems, vol. 39 no. 3, Fall 2022, covering 5,392 IT projects. The authors find cost overruns follow a power-law distribution with a fat tail, and warn that extreme overruns will occur and that their prevalence is grossly underestimated by managers assuming a normal or near-normal distribution.
- The curves in the first figure illustrate the two distribution shapes and are not plotted from the study’s data. The proportions in the second figure are illustrative of what we see rather than a published measurement. The ordering, and the relative size of the happy-path block, are what the figure is there to show.
- McKinsey with the University of Oxford, on 5,400 IT projects, reported an average 45% budget overrun. That figure and its context appear in why software projects run over budget.
Written September 2026.
