Vendor lock-in doesn't usually happen because of one big decision. It accumulates from dozens of small ones: a webhook here, a Zapier automation there, a script someone wrote during an on-call incident that quietly became load-bearing. None of those individual choices look risky at the time. The aggregate is what hurts.
Photo by Dimitri Karastelev on Unsplash
Why nobody notices until it's expensive
Each integration is built by whoever needed it, when they needed it, with no visibility into what else already depends on the same vendor. Six months later, that vendor is a single point of failure for five different workflows and nobody who built any single one of them realizes the total blast radius.
The fix isn't stopping people from building integrations. It's making the total integration surface visible, on a cadence, so the dependency count is a known number instead of a surprise.
This is the same failure mode that shows up in technical debt generally: no single decision looks unreasonable in isolation, but the aggregate becomes a genuine liability nobody explicitly chose. The difference with vendor integrations is that the debt isn't just harder-to-maintain code, it's negotiating leverage you've quietly handed to a vendor whose renewal pricing gets more aggressive every year you can't easily leave.
Why this matters more for smaller teams, not less
There's an intuition that lock-in is mostly an enterprise problem, since large companies have more systems and more integration points. In practice, smaller teams are often more exposed, because they lack a platform or infrastructure team whose job is specifically to track this kind of dependency. A twenty-person startup can accumulate the same integration sprawl as a five-hundred-person company, just with fewer people around who'd notice it happening.
A simple audit you can run this week
Start with the vendor's own developer console if it has one. Most platforms expose a list of active webhooks, API keys, and connected apps under account or security settings. That list is your starting inventory.
Cross-reference it against your automation platform (Zapier, Make, n8n, or an internal script repo). For every integration you find, capture three things: what triggers it, what it does, and who would notice if it silently broke tomorrow. That third question is the one teams skip, and it's the one that matters most when you're planning a migration.
# a minimal starting point for tracking integration dependencies
integrations = [
{"vendor": "acme_crm", "trigger": "deal.won", "action": "sync_to_billing", "owner": "finance"},
{"vendor": "acme_crm", "trigger": "contact.updated", "action": "update_mailing_list", "owner": "marketing"},
]
def blast_radius(vendor_name):
return [i for i in integrations if i["vendor"] == vendor_name]
Even a spreadsheet version of this is enough to start. The goal is just converting invisible dependency count into a visible one.
Turning the audit into an ongoing habit
Run this audit before adopting any new tool that another system might eventually integrate with, and again roughly every quarter for vendors you already depend on heavily. Integration count only grows over time; catching it early is cheaper than discovering it during a forced migration.
Assign an actual owner to this recurring audit, not just a shared responsibility that quietly belongs to nobody. Quarterly reviews that everyone agrees are important but nobody specifically owns tend to slip the first time a sprint gets busy, and the integration count that would've taken fifteen minutes to review in March becomes a much bigger surprise by September.
A more detailed inventory template
Once you've got a first pass done, formalize it slightly. For each integration, capture the vendor, the trigger event, the downstream action, the business owner, and a rough severity if it silently broke: cosmetic, annoying, or genuinely business-critical. That severity column is what turns a flat list into something you can actually prioritize during a migration planning conversation.
integration_inventory = [
{
"vendor": "acme_crm",
"trigger": "deal.won",
"action": "sync_to_billing",
"owner": "finance",
"severity": "critical",
},
{
"vendor": "acme_crm",
"trigger": "contact.updated",
"action": "update_mailing_list",
"owner": "marketing",
"severity": "annoying",
},
]
def critical_dependencies(vendor_name):
return [
i for i in integration_inventory
if i["vendor"] == vendor_name and i["severity"] == "critical"
]
A vendor with two critical dependencies and six cosmetic ones is a very different migration project than a vendor with eight critical dependencies, even if the raw integration count looks similar on paper.
What to do once you know the number
Finding out you have eighteen integrations against one vendor isn't itself a crisis. It's information. Some of those integrations might be trivial to replace, others might genuinely justify staying with the vendor even at a worse price, because the switching cost outweighs the savings. The point of the audit isn't to force a migration, it's to make sure that decision gets made deliberately, with real numbers, instead of by default because nobody had visibility into the total picture.
Where this becomes genuinely actionable is at renewal time. A vendor that knows you've quietly become dependent on eighteen integrations negotiates very differently than one who knows you've tracked that number and have a documented plan for the ones that matter least. Visibility into your own integration surface is, in a very literal sense, negotiating leverage.
We cover the broader risk framework, including data portability and contract exit terms alongside integration depth, in our guide to evaluating vendor lock-in risk before committing to a platform. Integration surface is one of four dimensions worth scoring before you sign, not after.
For teams standardizing how services talk to each other, the OpenAPI Initiative is worth a look, since documented, standard API contracts make future integration audits considerably less painful than reverse-engineering an undocumented one. The Zapier platform is also a reasonable place to centralize visibility if your team's automations are scattered across several no-code tools already, since it at least puts everything in one dashboard rather than five. More on how we approach this kind of work at 137foundry.com.
A pattern worth watching for specifically
One integration type deserves extra scrutiny during the audit: anything where a vendor's data flows into a system of record, meaning a place where the data becomes the canonical version rather than just a cached copy. A read-only dashboard pulling from a vendor's API is low risk, since you can rebuild the dashboard without touching the underlying data. A workflow where a vendor's webhook writes directly into your billing system or your customer database is a different category of risk entirely, because untangling that dependency means carefully verifying data integrity on both sides during the transition, not just rewiring a data source.
Flag these system-of-record integrations distinctly in your audit. They're usually a small fraction of the total integration count but represent a disproportionate share of the real migration risk, and they're exactly the ones worth prioritizing if you ever do decide a vendor relationship needs to end.
Making the audit sustainable long-term
The biggest risk to this whole practice isn't that teams disagree it's valuable, it's that the audit quietly stops happening after the first one or two rounds, once the initial enthusiasm fades and other priorities crowd it out. Tying it to an existing recurring ritual, a quarterly planning session or an existing infrastructure review, tends to work better than treating it as a standalone calendar reminder that's easy to snooze indefinitely. The goal is a habit that survives turnover on the team, not a one-time project that only exists because one person happened to care about it this quarter.
Top comments (0)