What makes integrations fragile (and how to build ones that last)
Integrations are where ambition meets reality. A business wants their website to talk to their CRM, their booking system, their inventory feed, their email platform. On paper, it's straightforward, connect A to B, pass the data, move on.
In practice, integrations are the most common source of long-term pain in digital projects. Not because the technology is hard. Because the decisions made during the build don't account for what happens six months later when something on the other end changes.
We've built and inherited enough integrations to see the patterns. Here are the three most common failure modes, and what to do differently.
Failure pattern 1
The "it works today" integration
This is the most common one. The integration gets built to match the current state of both systems. It works perfectly on launch day. Everyone's happy.
Then six months later, the CRM vendor updates their API. Or the booking system changes its data format. Or the client switches email platforms. And the integration breaks, silently, partially, or catastrophically.
The root cause isn't the change. It's that the integration was built as a point-in-time connection rather than a system designed to handle change.
- 01What good looks like
Build integrations with error handling that fails visibly, not silently. Use API versioning where available. Log every transaction so you can diagnose issues without guessing. And document what each integration depends on, which API endpoints, which data fields, which authentication methods, so when something changes, the fix is clear rather than archaeological.
Failure pattern 2
The "we'll sort the API later" integration
This one starts in the brief. Someone writes "integrate with [system]" as a line item, and the project moves forward without anyone investigating what that integration actually requires.
Then in week eight of a twelve-week build, the developer looks at the API documentation and discovers it doesn't support the data the client needs. Or the API requires an enterprise licence the client doesn't have. Or there's no API at all, just a CSV export that runs once a day.
The integration that was estimated at two days suddenly takes three weeks. The project timeline shifts. The budget stretches. And the client is frustrated because nobody flagged this earlier.
- 01What good looks like
Investigate every integration during discovery, not during development. Confirm API access, authentication, rate limits, data formats, and real-time vs batch availability before the project is scoped. The ten hours spent doing this during discovery saves weeks of rework during the build.
Failure pattern 3
The "single point of failure" integration
Some integrations become load-bearing walls without anyone planning for it. The website depends on a real-time API call to display pricing. The booking system feeds directly into the calendar with no fallback. The product feed from the warehouse system populates the entire e-commerce catalogue.
When that single connection goes down, and it will, the website doesn't degrade gracefully. It breaks. Products disappear. Prices show as zero. The booking page throws an error. And the client's customers see it before the client does.
- 01What good looks like
Design for failure. Cache data locally so the website can serve a recent version when the API is unavailable. Build health checks that alert you when an integration stops responding, before customers notice. And never let a third-party system be the only source of truth for data that's critical to the user experience.
Why
Fragile integrations start as rushed decisions
The pattern across all three failure modes is the same: the integration was treated as a technical task rather than a design decision.
"Connect the CRM" gets two lines in the brief and three days in the estimate. Nobody asks what data flows in which direction. Nobody checks whether the API supports webhooks or polling. Nobody defines what should happen when the connection fails.
And then six months later, the client is paying for emergency fixes on an integration that was never designed for the real world.
The fix isn't better developers. It's better questions at the start.
Questions
Three questions to ask before building any integration
- 01What happens when this breaks?
Not if when. Every external system will have downtime, API changes, or data inconsistencies at some point. The answer to this question determines whether you need caching, fallbacks, error handling, or monitoring. It also determines whether the integration is critical infrastructure or a nice-to-have.
- 02Who owns the other end?
If you're integrating with a system managed by a different vendor, a different team, or a third-party SaaS provider, you need to know who to call when something changes. The worst integrations are the ones where nobody on either side feels responsible for the connection between the systems.
- 03What data needs to flow, in which direction, and how often?
Real-time vs daily sync. Push vs pull. Full dataset vs incremental updates. These decisions affect architecture, cost, and complexity. Getting them right during discovery means the developer builds the right thing. Getting them wrong means rebuilding it later.
When
When to keep it simple
Not every integration needs to be engineered for resilience. If you're connecting a contact form to a CRM, a simple webhook is fine. If you're syncing a blog RSS feed to a newsletter tool, a lightweight automation handles it.
The investment in robust integration architecture should match the business impact of failure. If the integration going down means your customers can't book, pay, or access their account, invest in resilience. If it means a social media feed doesn't update for a day keep it simple and move on.
The goal isn't to over-engineer everything. It's to make conscious decisions about which integrations are critical and treat them accordingly.