Ask a software vendor who owns the code and they'll say you do. It'll be in the contract. It's usually true.
It's also close to irrelevant, because owning a codebase you can't hand to anyone else is a strange kind of ownership. The thing that actually locks a client in isn't the intellectual property. It's that four people understand how the system works and none of them work for you.
That's the real switching cost. It doesn't appear in any contract, and for most agencies it's a quiet commercial asset. Nobody sets out to build it. It accumulates, because documentation is the work that always loses to a deadline, and a year later the knowledge lives in a Slack history and three people's memory.
What the asymmetry actually costs you
Program comprehension, reading and understanding existing code rather than writing new code, takes up around 58% of developers' time according to research widely cited in the field. Broader surveys put the share of the working week actually spent writing or improving code at under a third.
For a client, that number becomes a bill. When you bring in a new team, whether you're switching vendors, hiring in-house or adding a second supplier, you pay for weeks of people reading. Not building anything. Reading. On a codebase with no current documentation, that ramp-up is somewhere between four and eight weeks per senior engineer before their output resembles what you're paying for.
Which produces a specific and familiar trap. You're unhappy with your vendor. You get a quote from another firm and it includes a discovery and onboarding phase that costs real money and delivers no features. So you stay. Not because switching is impossible but because the first invoice buys you nothing visible, and that's a hard thing to justify internally.
The vendor doesn't need to do anything sinister for this to work in their favour. They just need to not solve it.
Why it was never solved
Because keeping documentation current was, until recently, genuinely uneconomic.
Every engineer knows they should document. Everyone has been on a project where the docs were accurate for three weeks and then diverged. The problem was never willingness. Documentation decays at exactly the rate the code changes, so keeping it true means paying a tax on every merge, forever, and that tax is the first thing cut when a deadline moves.
So the industry settled on "the code is the documentation", which is true in the narrow sense that the code is authoritative and false in every sense that matters to a person trying to understand why it's like that.
That economic constraint is gone. Reference documentation, what this module does, what this endpoint expects, how these services relate, what this data model represents, can now be generated and regenerated cheaply enough that keeping it current is no longer a question of discipline.
What we do about it
We treat the handover as a deliverable from day one, not an event at the end.
Reference documentation generated and refreshed continuously. Module and service descriptions, API surfaces, data model documentation, environment setup. Regenerated as the code changes, so it doesn't drift. This is the category where AI is straightforwardly good, and the value is entirely in it being current rather than in it being eloquent.
Architecture decision records written by humans. The generated material tells you what the system does. It cannot tell you why the multi-tenant model is shared-schema, or why an obvious-looking optimisation was rejected. That context is the expensive part, it only exists in the heads of the people who were in the room, and it's what a new team most needs. We write these by hand, at the time, because reconstructing them later is impossible.
A README that works. Clone, install, run, with no tribal knowledge. Verified by having someone who hasn't touched the project follow it exactly. It's a low bar and most projects fail it.
A handover test, when you want proof. At an agreed point, not at the end of the engagement, we hand an engineer who hasn't worked on the project the documentation and a small real task, and see how far they get. What blocks them is what's missing. We'd rather find that out on our own time than during a transition.
What to ask your current vendor
You don't need to be planning a switch to run this. It's a health check.
"If we brought in a second team next month, what would you hand them, and how long until they were productive?" The answer tells you where you stand. "Two weeks and here's the documentation" is a different relationship from "well, they'd need to work alongside our people for a while."
"Can we have a copy of the documentation as it stands today?" Not a promise to prepare something. What exists right now. The gap between what's promised and what exists is the measurement.
"Which decisions in this system would be hard to explain to a new team?" A good vendor will have a list and will have written some of it down. A vendor who says there aren't any hasn't thought about it.
Then actually test it. Give the documentation to someone independent, a contractor, an in-house developer, a friendly engineer, with a small task. A day of someone's time buys you a genuine answer instead of an assurance.
The commercial argument, stated plainly
Making yourself replaceable is a strange thing for an agency to advertise, so it's worth being direct about why we do it.
A client who stays because leaving is expensive is a client who is, at some level, unhappy. That relationship shows up in how the work goes: reduced scope, more scrutiny, harder renewals, no referrals. It's a worse business than it looks like on the revenue line.
A client who stays because they keep choosing to is a different proposition. It requires being good enough that the choice keeps going your way, which is a more demanding standard and a more defensible position.
There's also a straightforward sales effect. The most common reason a prospect doesn't move away from a vendor they're unhappy with is fear of the transition. Being the firm that visibly solves that fear, for the client's next vendor as well as for ourselves, is a better argument than any case study.
And frankly, the alternative is a business model that depends on the client's difficulty rather than on our quality. That was never a good bet. It's a worse one now that the thing it depended on, expensive-to-maintain documentation, has stopped being expensive.
The test
Ask whoever builds your software what would happen if you replaced them next quarter.
If the honest answer is that it would be painful and slow, that isn't a technical problem you've discovered. It's a commercial position you're in, and it was built one skipped documentation task at a time.
Wondering where you stand with your current vendor? Tell us about your project and we'll tell you what a clean handover should contain.
Was this useful?
