There's a question almost nobody asks before commissioning a website, and it decides more than the design does: if you wanted to leave tomorrow, what would you take with you?
Try it on yours. If the answer is "the copy, pasted by hand off a screen", you don't have a website: you have a subscription to one. And that changes your position entirely when the price goes up, when the service shuts down, or when you simply want to do something the tool won't allow.
The three levels of lock-in
Level one: the closed platform. Wix, Squarespace, Framer and the rest. They work, some of them very well, and for certain projects they're the right call. But what you built lives inside and doesn't come out. No export returns a working site outside it. The day you want to move, you start over.
Level two: the code exists but you don't have it. More common than you'd think. The site is custom-built, the supplier keeps it in their hosting account, their repository and sometimes their domain, and you have a login to a panel. Technically it's yours; in practice you can't touch it or take it without their cooperation. If the relationship ends badly, your site is a hostage.
Level three: you have everything and nobody can use it. The code is in your account, but nothing was documented, the environment variables live in someone's head and there are no deployment instructions. It's yours, yes — but the next person in will charge you to decipher it before they can change a comma.
How it's avoided, concretely
This isn't about trust or good intentions. It's four material things:
The domain in your name and your account. Always. It's the cheapest thing to get right and the most expensive to fix later. If your supplier says they'll manage it "to keep things simple for you", ask for access anyway.
Hosting in your account. Vercel, Netlify, whichever — registered with your email and your card. The supplier joins as a collaborator. If they leave, they leave; your site doesn't.
The code in your repository. Not theirs. Give them permissions, not ownership.
Minimal documentation, written down. Where it's deployed, what environment variables are needed and what for, how a change gets deployed, and which external services it uses under which accounts. Half a page. It's the difference between someone else picking this up tomorrow and starting over.
Why I work this way, and what it costs me
Everything I build goes into the client's own accounts and ships documented. That isn't generosity: the alternative commits me to maintaining someone else's infrastructure indefinitely, and that's a liability, not an asset.
It also means I hold no lever to keep you. If in a year you want someone else to run it, you take it to them.
I'd rather you stayed because the work is good than because leaving is expensive.
When a closed platform is the right answer
Not everything needs code. If you need a landing page this week, you'll be editing it constantly and you aren't going to grow past that, a closed platform gives you more for less. What matters is knowing you're choosing that, not discovering it two years later when you want to move and can't.
The expensive decision is the one in between: paying custom-build prices and receiving platform lock-in.
The question for your next quote
Whoever writes it, ask: "Whose name do the domain, the hosting and the code end up in, and what documentation do I get?"
The answer tells you more about a supplier than their portfolio does.
If you want me to check what level your current site is at, send me the URL. What I deliver on every project is in web development.