Most lock-in is not contractual. It is the quiet kind: the code lives in the vendor's account, the deployment steps exist only in one person's head, and nobody else can get a working copy running. No clause created that situation, and no clause will fix it.
The checklist
Print this and use it on any vendor, including us.
1. Source code in your Git organisation
Not a zip file, not a shared drive, not their GitHub with you added as a collaborator. Your organisation, your billing, your ability to revoke access. The full history should be there — a squashed single commit on handover day tells you nothing about how the thing was built.
2. Documented environment variables
Every key the application reads, what it is for, and where the value comes from. A .env.example with a comment per line. This is the single most common reason a new developer cannot get a project running.
3. A seed script
Something that creates a working environment from nothing: schema, reference data, one admin user. Without it, "set up a local copy" becomes a week of archaeology.
4. A deployment runbook
The actual steps, written for someone who was not there. Which service, which branch deploys, what the build command is, how migrations run, what to do when a deploy fails. If the answer is "we just push and it works", ask what happens when it does not.
5. Database schema documentation
Tables, relationships, and — more usefully — the two or three modelling decisions that are not obvious. Why invoices and invoice lines are separate. Why the status field is an enum and not a boolean.
6. A recorded walkthrough
Screen and voice, thirty to sixty minutes. Both the admin interface and the code structure. This survives staff turnover on your side, which written documentation often does not because nobody reads it until they urgently need it.
7. Every account in your business's name
Hosting, domain registrar, DNS, database, payment gateway, email service, error monitoring, Play Console, Apple Developer. Registered to your business, billed to your card, with you as owner and the vendor as a collaborator you can remove.
This is the one people discover too late, usually when a domain is about to expire and nobody can reach the person who registered it.
8. Signing keys, for anything mobile
The Android keystore and the Apple credentials. Lose these and you cannot ship an update to your own app — you have to publish a new listing and ask every user to reinstall.
The one question that tests all eight
"If we hired a developer next month, could they take over without calling you?"
Ask it before you sign, not at the end. The answer shapes how the project is built, and a vendor who intends to deliver all eight will say so immediately because they have done it before.
What good vendors do differently
They treat handover as a thing that happens continuously rather than an event at the end. The code is in your organisation from the first commit, not moved there on the last day. The runbook is written as the deployment is set up, because that is when the details are known. The environment variables are documented as they are added.
Handover assembled at the end is always thinner than handover accumulated throughout, because by then nobody remembers why the odd configuration value was needed.
Why a vendor would want this
The obvious objection: does this not make it easy to leave?
Yes. That is the point, and it is not altruism. A client who can leave at any time is a client whose vendor has to keep earning the work every month, and that produces better work than a contract that makes leaving expensive. It also removes the conversation about lock-in from every future decision, which is worth more than the leverage it gives up.