There is a version of this work where the agency holds everything. The domain is registered to them, the hosting is on their account, the code is in their repository, and the analytics sit behind their login.
Nothing about that arrangement is illegal and plenty of firms run it. It is still the wrong side of a line, and it only becomes obvious at the exact moment you want to leave.
What being locked in actually looks like
It rarely looks like a fight. It looks like friction.
You want a second opinion on why the site is slow, and the person giving it cannot see anything. You want to change one line of copy, and it goes into a queue. You want to move on, and the handover becomes a negotiation rather than a transfer.
The relationship might be perfectly good the whole time. The problem is that you cannot test whether it is good, because you cannot leave.
What you should hold
Four things. If you have these, you are fine, whoever built it.
The domain. Registered to you, in an account you can log into. This is the one that matters most and the one most often wrong. The domain is your address. Everything else can be rebuilt.
The repository. The code, with its history, under your organisation. Not a zip file emailed at the end.
The hosting. The account the site deploys into, paid by you, with your developer invited to it. Invited, which means removable.
The data. Analytics, search console, form submissions, the customer list. Yours, in your accounts.
The reasonable exception
Some agencies genuinely run shared infrastructure, and there are real reasons for it. That is fine as long as it is stated, and as long as there is a written answer to one question: what happens on the day we part ways, specifically, and how long does it take?
If nobody can answer that in a sentence, that is the answer.
How I do it
Everything goes to your accounts. Domain, repository, hosting, analytics. I get invited as a collaborator and you can remove me in one click, without asking me.
Handover is not a ceremony at the end. It is where things live from the first day, so there is nothing to hand over.
I also write down the moving parts. Not a manual: where the configuration lives, what the deploy does, what to check when something breaks. Enough that another developer can pick it up without calling me, because the alternative is a document that only exists in my head, which is just lock-in with better manners.
Why I do it this way
Partly because it is fair, and partly for a less noble reason.
If you can leave at any point, then you staying means something. It means the work is good, not that leaving is expensive. That is a better position to build a business on than the alternative, and it forces me to keep earning the next project rather than collecting rent on the last one.
If you already have a site
You can check all of this in about ten minutes.
Look up your domain in a public WHOIS tool and see whose name is on it. Log in to your hosting and see whether you can. Ask where the code lives and whether you have access. Check whether the analytics account is yours or whether you have only ever been sent screenshots.
If any of those comes back wrong, it is fixable. Domains transfer, repositories move, hosting migrates. It is a slightly tedious afternoon, not a crisis.
Do it while everyone is still getting on. That is the easy time.
Building something along these lines?
Thirty minutes, no pitch. You describe the problem, I tell you whether it is worth building and roughly what it takes.
Book a call