Why the code has to stay yours
Vendor lock-in is rarely malice: it comes from how the contract was written and where the accounts live.
The moment you realise you're tied to a supplier isn't when things go wrong. It's when they're going well and you need a change: you ask for a quote, the number doesn't add up, you think about asking someone else, and you discover you can't. The code sits in an account that isn't yours, the domain is registered to them, and nobody knows how the database is built.
It's almost never a trap laid on purpose. It's the result of choices made for convenience, one at a time, without anyone writing them down.
The four things to ask for before you start
The repository is yours. Registered to your company, with the supplier invited as a collaborator — not the other way round. It costs nothing on day one and becomes impossible to fix on day one hundred.
The accounts are yours. Domain, hosting, database, third-party services: registered with your company's email address. Whoever works on the project can hold the passwords, as long as the account owner is you.
The decisions are documented. You don't need a manual: you need a file explaining how to start the project, where the environment variables live, why that database was chosen and what happens when an order comes in. Half a day of work that's worth months at the first change of supplier.
No proprietary pieces. If the work rests on a library that exists only inside the company that built it for you, the code is yours on paper only: nobody else can touch it.
The test to run
Just one, and you can run it at any time: if your supplier disappeared tomorrow, could another developer pick up the work by reading what's there?
If the answer requires a phone call to whoever wrote it, the work isn't finished. Knowledge that lives only in one person's head isn't an advantage for that person: it's a risk for you and a burden for them, because they'll always be the only one who can work on it.
Why I say this as a supplier
It seems counterintuitive for someone who writes software to explain how to change it without him. The reason is practical: a client who stays because they can't leave isn't a happy client, they're a client who leaves the moment they can — and in the meantime treats every quote as an imposition.
I'd rather people work with me because the work is done well. It's also the only way word of mouth works, and word of mouth is how most serious projects arrive.
If you're already in it
You don't have to redo everything. Start with the accounts: open accounts in the company's name and transfer domain and services, one at a time. Then ask for a copy of the code and put it in a repository of your own — even just as an archive. Then the minimum documentation, which you can commission as a job in its own right.
It's the kind of tidying nobody does until they need it. Doing it while everything works costs a tenth.