What is single-vendor dependency?

Single-vendor dependency is the organizational risk of entrusting a critical system, an entire technology area or the AI relationship to a single IT vendor, to the point where the company loses visibility and alternatives if that vendor disappears, changes terms or loses the key people who knew the project. It should not be confused with vendor lock-in, which is the technical cost of leaving a technology: here the problem is not the technology, it is having a single human and commercial point of contact for an essential piece of the business. The risk has three concrete faces: continuity (the vendor closes, gets acquired or shifts priorities and stops serving you), negotiating leverage (it knows it is irreplaceable and raises prices or terms at renewal), and knowledge (expertise on the system lives with two or three people at another company). It is a risk to manage without giving up the single vendor, which is often also the most efficient choice.

See also: Vendor lock-in · The technical and contractual cost of leaving a vendor: data, logic, skills. Measured before signing, not after.

A single point of contact is not the problem, an unmanaged risk is

Companies have a legitimate reason to look for a single vendor: coordinating five different suppliers on the same system, each blaming the other when something breaks, is unmanageable in practice. A single technical point of contact reduces friction, speeds up decisions and makes it clear who is accountable for what. Concentrating on one vendor is therefore acceptable, as long as it does not become captivity: a company can have a single operational contact and still remain free to change it, if it owns the code and data that vendor produced, if the technical documentation stays inside the company rather than in two consultants' heads, if the architecture uses open standards instead of proprietary formats, and if skills are transferred to the internal team during the project instead of being withheld as renewal leverage. A vendor that systematically refuses these four points is selling dependency, and should be treated as such during negotiation, without waiting for the contract to expire.

Enterprise example and designing the exit from day one

A recurring case: a mid-sized company hands its data platform and the entire AI layer built on top of it to a single system integrator. It works well for two years, then the integrator gets acquired by a competitor of the client, and the relationship ends overnight. The team left behind has access to the code, but not to the documentation of architectural choices, never written down because "they already knew it". Rebuilding costs more than the original platform. This is avoided by designing the exit at the start of the relationship: contractual clauses transferring code and intellectual property, a second vendor or a fractional CTO keeping independent technical oversight even when execution is delegated, periodic verification of data portability with a real export test, and a skills-transfer plan written into the contract from day one, not negotiated in an emergency.