An agency closes, a contract ends on bad terms, or the one person who understood the system simply leaves — and a business discovers, at the worst possible moment, that it never actually had the keys to what it paid for. This isn't a rare edge case; it's the predictable result of never asking, at the start of a relationship, what happens to everything if that relationship ends.
Access is the first thing to settle, not the last
Who holds the domain registration, the hosting account, the source code repository, the third-party API keys the system depends on — and are those accounts in the business's own name, or the agency's, with the business as a guest. This question is easy and slightly awkward to ask before signing a contract, and very hard and very expensive to resolve after a relationship has already soured. The right answer, in nearly every case, is that primary ownership of every account sits with the business, with the agency granted access to do the work — not the other way round.
Ownership of the code is a specific, contractual question
"We built it, so we own it until you pay us to hand it over" is a legitimate business model for some agencies, and a serious problem if a business didn't realise that was the arrangement it agreed to. The contract should state plainly, in writing, who owns the resulting code and assets, whether that ownership is immediate or contingent on final payment, and what happens to that ownership if the contract ends early — vague language here isn't an oversight, it's often exactly the ambiguity a difficult handover later depends on.
Documentation is what makes ownership actually usable
Owning code nobody can read is close to owning nothing. A system with no documentation of its architecture, its environment variables, its deployment process and its key decisions is, in practice, only operable by the person who built it — which means the business hasn't actually reduced its dependency on the agency just by holding the files, it's just made that dependency harder to see. Requiring basic handover documentation as a deliverable, not an optional extra, is what turns technical ownership into practical independence.
Exportability is the test that reveals real lock-in
A system built on proprietary tooling that only the original agency can operate, or on a platform that makes exporting data and configuration difficult or impossible, creates lock-in regardless of what the contract says about ownership. The honest test is simple: could a different, competent developer pick this system up and continue working on it within a reasonable amount of time, using only what's been handed over — and if the answer is genuinely uncertain, that uncertainty is worth resolving before the system is built, not after the original developer is gone.
Why this is cheapest to settle before the first invoice
Every one of these terms is a small, calm negotiation at the start of a relationship and a stressful, leverage-poor one after something has already gone wrong — asking for handover documentation from an agency that's still actively engaged costs almost nothing; asking for it from one that's already walked away costs a great deal, if it's even possible at all.
This sits alongside the same buy, build or configure decision — the right technical choice only stays right if the business can actually keep operating the system regardless of who built it.
Our software team hands over full ownership, documentation and exportable systems as standard, not as a negotiated extra — because a client who could walk away cleanly, and chooses to stay, is the only kind of relationship worth having.
