Every enterprise scoping meeting follows the same pattern. Features, design, timelines, budget. Then someone mentions integrations, and the entire plan shifts. "We just need it to connect to our CRM." "It should pull data from the finance system." "Can it sync with our HR platform?" Each one sounds like a line item. In practice, each one is a project within the project.
What You Need to Know
- System integration consistently accounts for 30-50% of total project effort on enterprise builds, but it's rarely budgeted that way
- Every integration has three hidden costs: the initial connection, the ongoing maintenance, and the failure handling
- Legacy systems without APIs multiply the integration effort dramatically
- Honest scoping of integration work is the single biggest factor in accurate enterprise project estimates
The Line-Item Illusion
In a project proposal, an integration looks simple. "Connect to Xero for financial reporting." One line. Maybe a few hours estimated. In practice, that line means:
- Understanding Xero's API documentation and authentication model
- Mapping data fields between your system and Xero's data structure
- Handling rate limits, timeouts, and API versioning
- Building error handling for when the connection fails
- Testing with real data, not the sanitised sandbox data
- Managing ongoing changes when Xero updates their API
That "few hours" is usually a few weeks. Multiply by three or four integrations and you've doubled the project timeline without adding a single user-facing feature.
Why It's Always Underestimated
Integrations are underestimated because they're boring. Nobody gets excited about field mapping and error handling. The interesting work is the application itself. So the scoping conversation naturally gravitates toward features, interfaces, and user experience. The integration work gets a nod and a rough number.
The other reason is optimism. The API documentation says it's straightforward. The vendor says their system "integrates easily." The developer who's done a similar integration says "it shouldn't be too bad." All of these are probably true in isolation and probably wrong in combination.
Every integration involves two systems built by different teams with different assumptions about data, authentication, and error handling. The gap between those assumptions is where the time goes.
The Legacy Multiplier
Modern systems with well-documented REST APIs are the easy case. The hard case, and the common case in NZ enterprise, is the legacy system that wasn't built to talk to anything.
No API. Data locked in a proprietary database. The only export option is a CSV that gets generated manually once a month. The vendor's "integration support" is a PDF written in 2009.
We've built integrations against systems like this. It works, but it takes creative solutions: scheduled data exports, screen scraping, middleware that translates between formats, database-level connections that bypass the application entirely. Each approach has tradeoffs in reliability, timeliness, and maintainability.
The integration tax on legacy systems isn't 30-50% of the project. It can be the majority.
We quote integration work as its own line item with its own discovery phase. Clients prefer that clarity over a doubled budget at month three.
John Li
Chief Technology Officer
How We Handle It Now
We've changed how we scope integrations at IDESIGN. Three rules:
Every integration gets its own discovery. Before we estimate the cost, we examine the target system's API, data model, authentication, and documentation. If the API doesn't exist or the documentation is thin, we build time for exploration.
We budget for failure cases. What happens when the API is down? When the data format changes? When a record exists in one system but not the other? The failure handling often takes longer than the happy path.
We separate integration from application. The integration layer is its own concern with its own tests, its own monitoring, and its own error reporting. When something breaks between systems, we need to know about it before the user does.
The integration tax is real and it's unavoidable. The only question is whether you account for it upfront or discover it mid-project. We've done both. The first way is better.