The most expensive mistake in a web project is not overpaying. It is discovering, later, that you do not control the domain, the hosting or the code you paid to have built.
The costliest thing that can go wrong with a website is not the price. It is finding out, a year later and usually during a dispute, that the domain is registered to your developer, the hosting is on their account, and you have no copy of the code you paid to build. At that point you do not own a website. You own a dependency. Here is how to make sure you own the real thing.
The domain is yours, in your name
Your domain name is your address on the internet and it should be registered to you, with your details as the registrant, in an account you can log into. It is fine for a developer to set it up for you. It is not fine for it to sit in their account where your business only exists at their goodwill. Ask for the registrar login, confirm your name is on the record, and keep the renewal date somewhere you will see it — a lapsed domain is one of the few web mistakes that is genuinely hard to undo.
The hosting account is yours too
The server your site runs on should be an account in your name, that you can access and that you pay for directly, or at least one you can take over without a fight. Hosting bundled invisibly into a monthly fee is convenient right up until you want to change developer, at which point it becomes the leash. You do not need to manage the server yourself. You do need to be able to.
The three logins to insist on
The domain registrar, the hosting account, and the website admin. If you hold those three, you own your web presence. If someone else holds any of them, you are renting it from them.
You get the source code and the admin
For a custom build, the source code is the thing you actually paid to create, and you should receive a copy along with the administrative access to run the site. This is not distrust — it is what "you paid for it" means. A professional relationship survives handover documentation. One that depends on you never being able to leave is not a relationship you want to be in.
Handover is a deliverable, not a favour
A project is not finished when the site goes live. It is finished when you have been handed the accounts, the code and a plain-language note of where everything lives and how to reach it. Ask for that handover to be part of the agreement from the start. A developer who builds well and hands over cleanly is the one worth staying with — precisely because they have made it easy for you to leave.
None of this is about mistrust
Insisting on ownership does not sour a good working relationship; it protects it. The best long-term partnerships are the ones where you stay because the work is good, not because leaving is impossible. Sorting ownership out at the start means the only thing keeping you together is the only thing that should — that the work is worth paying for.