Who Owns the Code of Your Website? What to Ask For in a Build Contract
Who owns the code of your website? A plain handover checklist: what to ask for in a website contract, which questions to ask before you sign, and the red flags.

About once a month someone asks me the same question in different words: what should I ask for in a website build contract? And right behind it, usually in a quieter voice, comes the real one: who owns the code of my website? That is not a legal question, and I am not a lawyer, so one line up front: none of this is legal advice. It is a checklist from someone who builds websites and systems, and who sees up close what stays in the client's hands when the relationship with the supplier ends, and what simply disappears.
Most owners sign a contract that talks about design, page count and a delivery date. Almost no contract talks about the day after. And the day after is what decides whether you bought an asset or rented an apartment without noticing.
The handover checklist: five things that must be in your name
The code. Not "a ZIP file by email". A real code repository that you own, one you could hand to a different developer tomorrow so he can pick up where the last one stopped. Without it, every small change has to go through one specific person on earth.
The domain. Your business address should be registered in your name, in your account, with the password in your hands. A domain registered to the supplier is the one thing that cannot be "rebuilt". It is your name.
The hosting account. The server or service that runs the site should be your account, paid by you directly. "We host it for you" sounds convenient. In practice it means your website lives inside an account you have no key to.
Every access. The content manager, the database, the analytics, the email service, the payments connection. A written list, with a login that is yours. Not "ask me and I'll go in for you".
Your data. Leads, clients, orders, form submissions. Ask how you export all of it to an open file, and ask to see one sample export before the final payment. An export nobody has ever tested is a promise, not a capability.
And above all of it, one small clause: what happens the day I walk away. The right answer is short. The site keeps working, everything already sits in your accounts, and you owe the supplier nothing to keep it running.
The questions to ask a supplier before you sign, not after
- Will the code be mine, in a repository under my name? When exactly do I get access?
- Will the domain be registered to me or to you?
- Will the hosting be my account, paid by me directly?
- Will I get a full written list of every access at handover?
- How do I export my data? Show me one export now.
- If I stop working with you tomorrow morning, what stops working?
- Who else, besides you, can step in and continue the work?
A serious supplier answers all seven without getting defensive, because he has good answers. Anyone who takes offense at the question has just answered it for you.
The warning signs
"We host it for you, don't worry." With no repository and no account in your name, that is not hosting. That is custody.
"You don't need to touch the code." Maybe true. Maybe you never will. But the right and the access should be yours either way.
"We work on our own closed platform." Ask what happens to the site if you leave. If the answer is "it gets deleted", you are not buying a website. You are renting one.
"We'll sort that out at the end." The most common sign, and the most expensive. Everything is easy to sort out before you pay, and very hard afterwards.
And the last one, the simplest of them all: you cannot leave without losing everything. If that is the situation, it is not a contract. It is a polite trap.
Why I bother writing this
I build websites and systems for small businesses, and at the end of every project I hand over the code and the keys. Everything sits in the client's own accounts: the domain, the hosting, the database, every access. If he gets tired of me tomorrow, the system keeps running exactly as before, and he owes me nothing to keep it running. I laid out the reasoning behind this in my post on owning your system, and you can see what I actually do.
I know how that sounds. It is simply how I would want someone to build for me. Print the checklist, take it to your next meeting, even if that meeting is not with me. And if you are still working out what your business really needs, the short questionnaire is a good place to start, with no sales call.
Want to know what your business's system needs? The smart questionnaire maps it in a minute. Then I get back to you personally with a report.
Start the questionnaire →Or start on your own: there are free tools you can run right now, with no form and no email.