The Internal Lock-in Trap: Five Risks Worse Than External Vendor Lock-in

Most CTOs and technology leaders have learned to fear vendor lock-in — the situation where a company becomes too dependent on a single supplier, platform, or agency. In response, they build an in-house development team to "take control." The irony is that this decision often creates a worse trap than the one they sought to avoid: an internal vendor lock-in, where one person knows the system better than all documentation combined, and whose departure can paralyse an entire business process overnight.

Below are five risks that constitute the internal lock-in trap — risks that most companies fail to account for in their technology strategy.

1. The External vs. Internal Lock-in Paradox

External vendor lock-in is a familiar and well-mapped problem: when a company's processes are too deeply tied to one supplier's technology, a "switching cost" emerges — a cost that makes changing suppliers painful. The concept's roots in academic literature reach back to the 1980s — notably Paul David's famous QWERTY analysis, which described how markets can "lock into" an inferior standard due to historical events (David, 1985), and W. Brian Arthur's work on increasing returns and lock-in dynamics in competing technologies (Arthur, 1989). A classic later example is Microsoft's 1997 internal memo, cited by the European Commission in its 2004 decision (paragraph 463): "[The Windows API] is so deeply embedded in the source code of many Windows applications that switching to a different operating system would require enormous switching costs. ... In short, without this exclusive franchise called the Windows API, we would have been dead long ago." (Wikipedia, Vendor lock-in)

The paradox is that companies who fear this risk often build exactly the same dependency patterns in-house — only without the external safeguards. An external supplier has a contract, a service-level agreement (SLA), a team that ensures continuity even if one person leaves, and a business incentive to maintain documentation and handover processes. The internal "supplier" — in reality, a single developer who built the system single-handedly — has none of these. When that person leaves, there is no SLA obliging anyone to hand over the system. The company has acquired a lock-in that is structurally worse than the one it originally sought to avoid.

2. Technical Debt as a Control Mechanism

Technical debt arises in any case — fast decisions, deadlines, and compromises are a natural part of development. The problem occurs when this debt accumulates uncontrollably and becomes its own justification: "only this person knows how the system really works."

According to McKinsey, technical debt accounts for approximately 40% of companies' IT balance sheets, and each new project incurs an additional 10–20% cost due to technical debt. 30% of surveyed CIOs said that more than a fifth of their "new product" budget actually goes to resolving technical debt. Most alarmingly: companies with the most severe technical debt (the bottom quintile) are 40% more likely to abandon or discontinue their IT modernisation efforts — compared to the top quintile (McKinsey, 2023).

In in-house development, this risk is doubled: complexity accumulates not only in the code but also in one person's head. Every new "quick fix" increases both the technical debt and the dependency on the one person who can navigate through the mess.

3. Résumé-Driven Development

"Résumé-driven development" (RDD) describes the phenomenon where technology choices are made not for business need but for the developer's career interest — a trendy framework or architecture is selected because it looks good on a CV, even if a simpler solution would be a better fit. The term was popularised in the software community in the mid-2010s (Martin Jee, 2015), but until recently it lacked an empirical foundation.

In 2021, researchers at the University of Stuttgart conducted the first scientific study of this phenomenon, surveying 591 software professionals — 130 in recruiting and 558 in technical roles (some respondents held both roles). The results were clear: 60% of recruiters admitted that technology trends influence their job postings, and 82% of software engineers believed that using trendy technologies in their daily work makes them more attractive on the job market (Fritzsch, Wyrich, Bogner & Wagner, 2021).

From the company's perspective, the consequence is simple: when architecture decisions are born from career interests rather than business needs, the system becomes more complex than the business actually requires — and that complexity can typically only be managed by the one person who made the decision.

4. Key Person Dependency and the True Cost of Replacement

Software development uses the concept of "bus factor" to describe this risk — the minimum number of people whose departure would halt a project entirely. A bus factor of 1 means that one person is the system. In 2016, Avelino and colleagues analysed 133 popular GitHub projects and found that 65% of them had a bus factor of two or less (Avelino, Passos, Hora & Valente, 2016; summarised in Wikipedia, Bus factor). In other words: in most software projects, the departure of one or two people is enough to create a critical knowledge vacuum.

This is where the "true cost of replacement" comes into play — and it is higher than it appears from payroll lines. Gallup estimates that replacing an employee in a technical role costs the company approximately 80% of their annual salary; for managers, as much as 200%. And that is only the direct replacement cost — in software development, the following must be added:

• months of reduced team productivity during the transition

• the new person's need to understand the system in reverse, without properly documented logic

• errors made during the learning curve in areas that were previously "self-evident"

• features and deadlines that simply go unmet during the transition period

When that one person is simultaneously the sole architect of your e-commerce platform, ERP integration, or automated workflow, this is not a personnel cost — it is a business continuity risk.

5. False Economy: Apparent Cheapness vs. True TCO

In-house development appears cheaper at first glance than an external partner, because only the visible line is comparable — the developer's monthly salary. But that number does not include the true "total cost of ownership" (TCO), which encompasses recruitment, knowledge transfer, onboarding, opportunity cost (what was not built during that time), and the replacement cost described above when the key person leaves.

The same TCO logic that technology companies use to evaluate vendor lock-in — where a "low initial price" hides a high switching cost (Wikipedia, Vendor lock-in) — applies in exactly the same way to in-house development. When you add McKinsey's data showing that technical debt already adds 10–20% to project costs for every new development (McKinsey, 2023), "cheap" in-house development often becomes the most expensive choice in the company's real balance sheet — except that this cost appears years later, not on the monthly payroll.

Two Brief but Important Additional Risks

Innovation paralysis. When a system is tightly coupled to one specific person's head, every change becomes risky — and the organisation quietly stops innovating, because the perceived cost of change is too high. The classic escape from this trap is incremental modernisation, not a big "all at once" rewrite — an approach known as the Strangler Fig pattern.

Documentation theatre. The standard response to key person risk is the requirement: "document everything." But in fast-moving software, documentation ages faster than code, and mandated documentation quickly becomes mere theatre — paper that no one reads or updates. The real solution is not more documents but architectural isolation: a modular architecture with clear interfaces that makes the system understandable even without anyone carrying the full context in their head.

The Way Out Is Not "In-house vs. External" — It Is Structure

The most common false conclusion from all this is: "in-house development is bad, hire an agency." This is misleading. The problem is not who writes the code but whether knowledge and responsibility are concentrated in a single bottleneck — whether that is one developer in-house or one freelancer externally. Both internal and external lock-in arise from exactly the same source: an architecture that is too tightly coupled and knowledge that exists only in one person's head.

The real defence is two-fold: a modular architecture with clear interfaces that does not depend on one person's memory, and a team — not a single expert — that is continuously responsible for the entire solution.

This is why our own approach is built on modular architecture and documented interfaces — not on tacit knowledge residing in one person's head. When one component needs a change, the entire system does not need to be rebuilt. For the same reason, we do not split our services into standalone "projects" with different people responsible for each, but build one team's responsibility across platform, integrations, and automation. This way, no single individual becomes your company's bus factor — regardless of whether that person sits in your office or ours.