Nobody signs a contract expecting to lose control of their own codebase. It happens slowly, through small conveniences that each made sense at the time, until the day you price out a switch and realize the number is absurd. This is a story about how that dependency gets built, and what it takes to dismantle it.
TL;DR
- Lock-in is operational, not contractual. The clause you can exit in 30 days means nothing if only the vendor knows how the deployment works.
- The five mechanisms are undocumented code, vendor-owned infrastructure and credentials, exotic architecture only they can maintain, staffing rotations that reset context, and documentation deferred forever.
- Change orders inflate once you cannot credibly walk away. Vendors price against your alternatives, and your alternatives shrink every quarter.
- The exit needs a knowledge-transfer clause with acceptance tests, not a promise of a handover doc.
- Own the accounts from day one. Repos, cloud org, CI, secrets manager, DNS, monitoring, all in your name, vendor engineers as invited members.
- Staff augmentation prevents the failure structurally because engineers work inside your repos, your rituals, and your review process, so context accumulates in your org instead of theirs.
The composite scenario
What follows is a composite, assembled from patterns that recur across engineering orgs that outsourced a core system. It is not a specific client, and no detail here identifies one.
A Series B fintech with 14 in-house engineers needs a payments ledger rebuilt. Hiring senior backend people takes them roughly 5 months per role, so they hand the project to a 9-person dev shop at an illustrative $95 per hour, about $150K per quarter. The shop delivers. The ledger ships two weeks late and works.
Eighteen months later the same shop bills roughly $210K per quarter, now covering the ledger, the reconciliation service, two internal admin tools, and the CI pipeline. The VP of Engineering asks a reasonable question: what would it cost to bring this in-house? The honest answer comes back at 7 to 9 months of parallel work plus two new senior hires, and nobody on the internal team can describe how the reconciliation service decides which transactions to retry. That is lock-in. Not a clause. A knowledge gap with a price tag.
Mechanism one: the code exists, the reasoning does not
The repository is full. Test coverage sits at a respectable 71%. What is missing is every decision that produced it. Why the ledger writes to two tables. Why there is a 400ms sleep in the retry loop. Why the reconciliation job cannot run on Sundays.
That reasoning lives in the vendor’s Slack, in tickets in the vendor’s Jira, in the heads of three engineers who were on the project in year one. When you ask, you get an answer that is correct and useless: “it’s historical, we can look into refactoring it.” Every question routes through them, which is exactly the arrangement that makes them hard to replace.
Tribal knowledge is the asset the vendor actually sells you. The code was always going to be deliverable. The context is what they keep.
Mechanism two: they hold the keys
This one is embarrassing and extremely common. Check who owns the following, right now, before finishing this post:
| Asset | Common vendor-held setup | What you want |
|---|---|---|
| Git organization | Vendor’s GitHub org, your repos inside it | Your org, vendor as outside collaborators |
| Cloud account | Vendor’s AWS/GCP account, rebilled to you | Your account or org, vendor with scoped IAM roles |
| CI/CD | Vendor’s CircleCI or Actions runners | Your CI, your runner credits |
| Secrets | Vendor’s 1Password vault or Parameter Store | Your secrets manager, break-glass access documented |
| DNS and certs | Registered by vendor’s ops person | Your registrar, your account |
| Monitoring and paging | Vendor’s Datadog and PagerDuty | Your accounts, vendor invited |
| App store and package registries | Vendor developer account | Your accounts |
Every row where the vendor owns the asset converts a commercial negotiation into a hostage situation. The migration itself is not hard. Moving a cloud account, rotating credentials, and reconfiguring CI is a few weeks of work in an illustrative range of 2 to 6 weeks. The problem is that it is work you cannot do while also fighting about the renewal.
Mechanism three: architecture nobody else can hold
Some vendors build systems that only they can operate, and not always on purpose. A homegrown orchestration layer instead of Temporal or Step Functions. A custom ORM. Configuration in a proprietary YAML dialect that a vendor-authored generator expands. Four microservices where a modular service would do, because the vendor billed by the team and the team was four people.
The tell is when your hiring pipeline breaks against your own stack. If a strong senior candidate needs 4 months to become productive in a system of that size, the system is the problem. Non-standard architecture raises your replacement cost more than any contract term.
Ask for this in every architecture review: what is the off-the-shelf alternative to this component, and why are we not using it? Written down, in the PR. Vendors who answer well are fine partners. Vendors who bristle are telling you something.
Mechanism four: rotations that reset the clock
The engineer who built the ledger left the vendor’s team in month 7. She was replaced by someone competent who spent his first six weeks reading code. Then he moved to another account, and someone else arrived. Across two years, roughly 11 people cycled through your project.
You paid for each ramp-up. And the accumulated context did not accumulate anywhere at all, because it lived with individuals who moved on and nobody owned the write-down. Meanwhile “we’ll document it next sprint” appeared in 14 consecutive sprint plans, and never once as a ticket with an assignee, because unbilled documentation is the first thing to lose a priority fight inside a shop running on utilization targets.
Mechanism five: change orders priced against your alternatives
Once the switching cost is high, pricing stops tracking the work. A change that would have been quoted at 40 hours in year one becomes 90 hours in year two, framed as complexity, risk, and regression surface. Some of that is real. Some of it is the vendor pricing against your alternatives, which they can estimate as well as you can.
The signal to watch is not the rate. It is the ratio of estimated hours to shipped scope, tracked quarter over quarter. If the same class of feature costs 30 to 50% more hours than it did a year ago and the codebase has not fundamentally changed, you are paying a dependency premium.
The exit playbook
Run this whether you plan to leave or not. Preparing to leave is what makes staying reasonable.
1. Knowledge transfer with acceptance criteria. A handover document is not a deliverable, it is a gesture. Define the transfer as tasks your engineers complete unaided: deploy to production, roll back a release, add a field end to end, resolve a synthetic incident from the on-call runbook, run the disaster recovery restore. Sign off happens when your people do it with the vendor watching in silence. Budget 3 to 5 weeks of vendor time, priced in advance, before renewal leverage disappears.
2. Ownership checklist. Work the table above, row by row. Add: IP assignment for all contributors including subcontractors, source code escrow only where a third-party dependency requires it, and written confirmation that no vendor-proprietary library remains in your build.
3. Parallel staffing overlap. Do not cut over. Bring in your own engineers for an illustrative 8 to 12 weeks of overlap, with your people owning on-call from week 3 while the vendor stays reachable but not responsible. On-call ownership is what forces knowledge to move. Nothing else does it as fast.
4. Rebuild the decision record. As your engineers learn each subsystem, they write the ADR the vendor never wrote. Not documentation for its own sake. The specific answer to “why is this like this,” which is the thing you were paying rent on.
Why staff augmentation does not produce this failure
The difference is where context lands. In a project outsourcing model, the vendor owns the process, so process knowledge, tooling, and history all pool on their side. That pooling is the lock-in. It is a structural output of the model, not a sign of a bad vendor.
Under staff augmentation, engineers join your repos, your sprint planning, your code review, your on-call rotation, and your incident reviews. Decisions get recorded in your ADRs because that is where your team records decisions. When someone rolls off, their knowledge is already in your systems and in the heads of teammates who stayed. You still lose a good engineer. You do not lose the ability to operate your product.
That is the practical test for any engagement, and it is worth asking out loud before you sign: if this partner disappeared next Friday, could my team deploy on Monday? If the answer is no, you are not buying capacity. You are renting access to your own software.
Frequently Asked Questions
How do I tell normal vendor reliance from real lock-in?
Reliance means the vendor does work faster than you could. Lock-in means your team cannot perform basic operations without them. Test it: have an internal engineer deploy the system, roll it back, and resolve a simulated alert, alone. If that fails, you have lock-in regardless of what the contract says.
The vendor built everything. Do we even own the code?
Usually yes, but check the contributor chain. Many shops use subcontractors whose IP assignment does not flow through to you, and a surprising number of engagements have no assignment language for AI-assisted or third-party contributions. Ask for a signed contributor list with assignment confirmed for every name.
What does a real knowledge transfer cost?
An illustrative range is 3 to 5 weeks of two vendor engineers' time, plus 8 to 12 weeks of overlap on your side. It is not cheap, and it is far below the cost of an emergency transition after a relationship breaks down. Negotiate and price it while renewal is still on the table.
Can we ask a vendor to move repos and cloud accounts mid-engagement?
Yes, and the reaction tells you a lot. The migration is a standard piece of work in the range of 2 to 6 weeks. A partner focused on the engineering will schedule it. A partner focused on retention will explain why it introduces unacceptable risk.
Does staff augmentation just relocate the dependency to individual engineers?
Individual dependency is real, and you manage it the same way you manage it for full-time employees: pairing, review requirements, rotating on-call, and no single owner for any production system. The difference is that these controls work when the engineer sits inside your process, and they are unenforceable when the work happens inside someone else's org.
We are mid-contract and stuck. Where do we start?
Start with credentials and accounts, because that work is unambiguous and does not require the vendor's cooperation to plan. Then pick the single system whose loss would hurt most and run a knowledge transfer on that one alone. One subsystem your team fully owns changes the negotiation more than any letter from your lawyer.
