The two pieces before this one were about what a vendor brings with them and how their system changes underneath you. Both are ongoing costs of the relationship. There’s a third that only shows up if you try to end it: the cost of leaving. It starts near zero on the day you sign and grows every time you write code against their model, store an identifier they issued, or build a workflow around a feature only they have. Nobody schedules that growth, and most teams have no idea what the current figure is until they need it.

The parts of the bill aren’t hard to name. There’s the code — every call site, every place their vocabulary leaked into yours, every workaround for one of their quirks. There’s the data — records living in their system, identifiers of theirs stored in yours, history that may or may not be exportable in a form anything else can read. There’s the operational knowledge: runbooks, dashboards, and the accumulated understanding of how the thing actually behaves. And there’s the part that isn’t yours to move at all — customers who integrated with them because you did, contracts that reference their capabilities, compliance evidence built on their certifications.

Knowing the number isn’t the same as avoiding it. Some lock-in is worth accepting cheerfully: the vendor that does something genuinely hard, or that would take you two years to replicate, has earned the dependency, and contorting your architecture to stay portable from a service you’ll never leave is a cost with no matching benefit. The abstraction-layer instinct can go too far in exactly this way — a wrapper thin enough to contain their semantics is useful, while one designed to make two hypothetical vendors interchangeable usually ends up implementing the worse half of both.

Where the number matters is in decisions that quietly increase it. Storing their identifier as your primary key rather than alongside your own is a small convenience that makes migration a data project instead of a code project. Letting their concepts become your domain model — their statuses, their entity names, their categories — means a switch requires rewriting how your product thinks, not just how it calls out. Exporting your own copy of data you care about, on a schedule, costs little and preserves the option. These are cheap when made deliberately and enormously expensive to reverse, which is the same asymmetry that runs through everything this blog keeps returning to.

So the close of this thread isn’t “avoid dependencies” — that’s not an option worth wanting. It’s that a dependency is a relationship with terms, and the terms include what happens if it ends: because they get acquired, or triple their prices, or sunset the product, or simply stop being good at the thing you needed. None of those are in your control. What is in your control is knowing, roughly, what your exit would take — and having made the handful of cheap choices along the way that keep the answer from being “we can’t.”