You paid a freelancer. The site is live. Six months later you want to change hosting, or hire someone else, or just log in and fix a phone number. Then you find out the domain is registered to the freelancer, the hosting bill goes to their card, and nobody can say where the code lives.
It happens often enough that ownership is the first question I'd ask before any design or price talk. I'm Ilya, a solo developer based in Bali. I've been building sites and apps for four years, with 40+ projects behind me. This is the checklist I'd use if I were the one hiring.
This is general information, not legal advice. Copyright and contract law differ by country and state. For a large project, show your contract to a lawyer.
1. The domain: whose name is on the registration?
The domain is your address on the internet. The person or company listed as the registrant is the holder of record. Under ICANN's registrar agreement, that holder carries responsibility for the registration and its use (ICANN, 2013 Registrar Accreditation Agreement).
If a freelancer buys the domain "for convenience" and lists themselves, you are renting your own address from them.
Require these three things:
- The registrant is you or your company.
- The registrar account is yours, not just a login to theirs.
- The contact email on the registration is one you can read.
The safest setup is plain. You open the registrar account, you pay for the domain, and you invite the freelancer as a helper if they need to change DNS records.
2. Logins that really reset to you
Owning the domain on paper does not help if the only working login belongs to someone else. Check where the password reset email goes. Turn on two-factor authentication yourself. Do the same for DNS if it lives in a separate service such as Cloudflare: either the account is yours or the records are moved to yours.
3. Hosting: whose account runs the site?
There are two common patterns.
The freelancer hosts your site on their own plan. Cheap and easy for them. For you, the site depends on their bill and their inbox. If you accept this, get a written promise to export everything on request, with a named person who receives the files.
The site runs in a hosting account opened in your name, and the freelancer is invited as a user. You pay the provider directly. If you part ways, you remove the freelancer and the site keeps running.
The second option costs a little setup time and saves a lot of pain later. Ask for it.
4. The code: where it lives and what you receive
For a WordPress site, "the code" means theme files, plugins, the database and uploaded media. For a custom or static site, it means a repository, usually on GitHub or GitLab.
Put these questions to the freelancer in writing:
- Where is the source code stored today?
- Will I get a full copy, or access to the repository, at handover?
- Does the copy include build and deploy instructions, so a different developer can publish it?
- Are any plugins, themes or fonts licensed to you personally rather than to me?
A zip of compiled files with no source and no instructions is a handover on paper only.
5. Copyright: who owns the work, legally?
Many people assume that paying for a site means owning it. The law is often less generous.
In the United States, the Copyright Office explains that a hired independent contractor can transfer copyright only through a signed written agreement. A commissioned work counts as "made for hire" only if it fits a short list of categories and the written agreement says so (U.S. Copyright Office, Circular 30).
In Australia, IP Australia states that intellectual property created by a contractor generally belongs to the contractor unless the contract says otherwise (IP Australia, Who owns IP). The Australian law firm LegalVision adds that a valid assignment of copyright has to be made in writing (LegalVision).
The practical reading for a client: if the contract is silent, don't assume you own more than the right to use what you were given. Get the transfer in writing.
A good clause covers three things.
- Rights in the work made for you pass to you, usually once you have paid in full.
- The freelancer keeps their own general tools and libraries and gives you a licence to use them inside your site.
- Third-party material (stock photos, paid plugins, fonts) is listed with its licence terms, so you know what you may reuse.
6. Everything around the site
A site rarely lives alone. List every account it depends on and ask who holds each one:
- Google Analytics and Search Console
- Email sending (contact form, newsletters)
- Payment or booking tools
- The site's admin account, with full rights for you
- Any AI or API keys the site uses (if the site has an AI chat, see how to keep it accurate)
For each line, the right answer is "it's in your account" or "it moves to you at handover."
7. Handover: what you hold on delivery day
Treat it as a receipt. On the day the site goes live, you should have:
- Domain registrar login, in your name
- Hosting or deployment login, in your name
- Admin login to the site itself
- A copy of the source code, or repository access
- A list of third-party accounts and who pays for each
- The copyright terms, in writing
If one is missing, ask for it before the final payment. After the final payment you have lost your leverage.
8. What happens if you stop working together?
Ask it directly: "If we part ways in a year, what do I walk away with, and how fast?" A confident freelancer answers in two sentences. A vague answer tells you something too.
Red flags in a quote or contract
- The domain is "included" but the registrant is never named.
- Hosting is "managed for you" with no mention of exporting the files.
- The contract says nothing about copyright, or says the developer keeps all rights.
- The final handover is "on request" with no list of what you receive.
- Every question about access gets the answer "don't worry about it."
Any one of these is a reason to ask again in writing.
How this looks in my own work
I apply the same logic to apps. For a client's mobile app, the Apple and Google developer accounts are opened in the client's name and paid by the client, so the app belongs to the client's account from day one. The full story is in my guide to publishing an app in both stores.
For websites, a static build makes moving easy. The site for Nexora Legal, a legal-services firm, has 40+ pages and is a static site. A static site is a set of files rather than a database behind a login, so it can be moved between hosts and developers without a rebuild. Whoever you hire, use the checklist above and ask for the answers in writing before you pay.
A website from me starts at $300. Payment is by bank transfer (to an Indonesian account), PayPal or crypto (USDT or USDC).
The short version
Before you pay a freelancer for a site, get a clear yes on four things:
- The domain is in my name.
- The hosting is in my account, or I get a full export on request.
- I receive the source code.
- The copyright transfer is written down.
Published: . By Ilya Litau, more on the About page.
Want a site you fully own?
Tell me what you are building. Domain, hosting and code are set up in your name from the start.