The five checks
- IP assignment written into the contract, not implied by the invoice. In most jurisdictions the developer owns what they write unless the contract says otherwise.
- The repository lives in your GitHub or GitLab organisation from the first commit, with the agency added as a collaborator, never the reverse.
- Cloud, domain, app store and payment accounts are registered to you, with the agency granted access. This is the single most common lock-in and the hardest to unwind.
- Handover documentation is a named deliverable with an acceptance criterion, not a promise at the end.
- A holdback, commonly 20%, released on acceptance rather than on delivery.
What it looks like when it is wrong
The pattern we see in audits is always the same. The client paid in full, the code is in the vendor's private account, the AWS bill goes to the vendor's card, the app is published under the vendor's developer account, and nobody wrote anything down. None of that was necessarily malicious. All of it is now the client's problem.
On source code escrow
Escrow is usually the wrong instrument for an SME build. It costs money annually, releases only on defined trigger events, and hands you a code drop with no running infrastructure. Owning the repository and the accounts from day one gives you everything escrow promises, continuously, for nothing.
Why any agency should welcome this
A vendor whose retention depends on you being unable to leave has an incentive problem that shows up eventually in their work. Removing the lock-in means the work has to be the reason you stay, which is a healthier arrangement for both sides, and it is how we contract.