Here is the verdict, and it irritates some of my colleagues: in most countries, paying a freelance developer in full does not by itself make you the owner of the code. Copyright begins with the person who typed it, and it moves to you only through a signed written assignment. I am Khaled Ahmed, a full stack developer in Cairo with 39+ production projects delivered across eight countries. This is the clause I insist on before I write a line.
1. The short answer: money buys delivery, paper buys ownership
Two different things happen when you hire a developer. You pay for the work to be done, and separately, ownership of what was produced is either transferred to you or it is not. The invoice handles the first. Only the contract handles the second.
Copyright in software arises automatically the moment the code is written — that is the rule across every country that signed the Berne Convention, which is effectively all of them, Egypt, Saudi Arabia, the UAE, Kuwait, the UK, France, Germany and Switzerland included. No registration, no filing, no stamp. And it arises in the author. The author is the developer, not the person who commissioned the work.
An employee is the exception in most systems. If a salaried engineer on your payroll writes code inside the scope of their job, the economic rights typically sit with the employer by operation of law — that is spelled out for software in Germany (UrhG §69b), and follows from the general employment rules in France (CPI L113-9) and the UK (CDPA s.11(2)). Egypt deserves an explicit flag here, because it is the jurisdiction most of my readers sign in: Law 82 of 2002 contains no general employer-ownership rule for works created by employees, so even the employment case there is driven by what the contract actually says. A freelancer, meanwhile, is not an employee anywhere. That is the whole point of the arrangement — and it is also the reason the default flips.
The one sentence to remember: "I paid for it" is a payment fact, not an ownership fact. In the United States (17 U.S.C. §204(a)) and the United Kingdom (CDPA 1988 s.90(3)), a transfer of copyright must be in writing and signed by the person giving it up. That writing can be electronic — a typed name in an email can satisfy the requirement under the US E-SIGN Act — but a verbal agreement almost never satisfies it, a payment receipt never does on its own, and a WhatsApp thread that never mentions copyright is not an assignment.
What you almost certainly have without a contract
You are not left with nothing. Where there is no written assignment, courts in common-law jurisdictions have generally found an implied licence — the client may use the deliverable for the purpose it was obviously commissioned for. If I build you a shop, you may run the shop. The problem is that an implied licence is the minimum the court thinks is necessary, and it usually does not include:
- The right to hand the source code to a different developer and have them modify it.
- The right to resell, sublicense or white-label the system.
- The right to reuse the codebase for a second brand, a second country or a second product line.
- Exclusivity — the developer may be free to build the same thing again for your competitor.
- Any claim on the code at all if you are in a dispute over the last invoice.
That last one is where most real fights start. Not with theft. With ambiguity plus a disagreement about scope.
2. "The code" is not one asset — it is at least seven
The single biggest reason people get burned is that they negotiate ownership of "the website" as if it were one object. It is not. It is a pile of separate assets held in separate places under separate legal regimes, and you can absolutely own the code while being locked out of the live product.
| Asset | Who holds it by default | What to demand in writing | Cost of getting it wrong |
|---|---|---|---|
| Bespoke source code | The developer (author) | Full assignment of economic rights on final payment | Cannot legally hire anyone else to modify it |
| Domain name | Whoever is the registrant of record | Registrar account in your company name, your email, your card | Total loss of brand and email if it lapses or is held |
| Hosting / VPS / AWS account | Whoever opened the account | Root account owned by you; developer gets an IAM or sub-user | Site goes dark when a card expires or a relationship ends |
| Git repository | Whoever owns the GitHub/GitLab organisation | Org owned by your company from day one | You lose history, branches, issues and CI config |
| Database and customer data | You, almost always — but only if you can reach it | Scheduled off-site backups you can restore without the developer | Regulatory exposure plus an unrecoverable business |
| Third-party licences (themes, paid plugins, Nova, fonts, stock photos) | The licensor; the seat belongs to whoever bought it | Licences purchased in your name, keys handed over, list documented | Silent breach, or the feature stops working at renewal |
| App store listings (Google Play, App Store) | The developer account that published | Publishing under your own developer account from the first upload | A transfer process, a wait, and sometimes a full re-review |
I have shipped seven apps to Google Play. Moving an app between developer accounts is possible — Google supports an app transfer flow and Apple supports one in App Store Connect — but both require both parties to cooperate, both accounts to be in good standing, and specific transaction identifiers. It is a bad day. Publishing from your account on day one is a good day. If mobile is part of your build, read what the store actually demands before you start, because the rules move: I covered the current testing gate in Google Play's 12-tester requirement.
3. Do I own the code once I have paid in full?
Only if the contract says so. Full payment is a condition that a well-drafted contract attaches the transfer to. It is not the transfer itself.
These are the systems my clients most often operate under, and the reasoning is similar elsewhere:
| Jurisdiction | Default owner of commissioned code | Written assignment required? | Note |
|---|---|---|---|
| United States | The freelancer | Yes — signed writing | Software commissioned from a contractor generally does not fit the statutory "work made for hire" categories, so labelling it as such is not enough on its own; an express assignment is the reliable route |
| United Kingdom | The freelancer | Yes — in writing, signed by the assignor | Employees are the exception; contractors are not. Courts have implied narrow licences where nothing was agreed |
| France | The author | Yes, and usually itemised | CPI L131-2 and L131-3 expect the rights, purpose, territory and duration to be spelled out one by one. Moral rights are perpetual and cannot be signed away wholesale |
| Germany | The author | No general written-form rule — and no assignment is available at all | Copyright itself is non-transferable under UrhG §29. What you take instead is an exclusive, transferable, sublicensable grant of exploitation rights (Nutzungsrechte) under §31. Note §69b already gives the employer the economic rights in employee-written software. Put the grant in writing anyway |
| Switzerland | The author | Not required by statute (URG art. 16) — do it in writing regardless | Transfer is permitted with no form requirement, which means an unwritten deal is valid in theory and unprovable in practice. Moral rights stay with the author |
| Egypt | The author | Yes — and the assignment is expected to specify the rights, purpose, duration and territory | Under Egypt's IP law (Law 82 of 2002), moral rights are perpetual and not assignable; only economic rights move |
| Saudi Arabia / UAE | The author, with statutory carve-outs for works made under employment or commission | Yes — written, itemised | Moral rights are protected and non-assignable. Do not rely on the carve-out; write the clause |
Two honest caveats on that table. First, I am a developer who has signed a lot of these agreements, not a lawyer — for anything above roughly USD 20,000 in value, pay a local lawyer for two hours and have them read the IP clause. Second, statutes get amended: the UAE replaced its 2002 copyright law with a 2021 federal decree-law, and Saudi enforcement moved to SAIP after 2018. If your contract cites an article number, check that the number still exists as of the date you sign.
Practical rule: in almost every jurisdiction listed above, the correct instruction to your lawyer is the same — "assignment of all economic rights in the bespoke deliverables, effective on receipt of cleared final payment, worldwide, in perpetuity, irrevocable." The one place that sentence cannot be executed literally is Germany, where copyright is not assignable at all; there you ask for an exclusive, transferable and sublicensable grant of exploitation rights instead. The commercial effect is the same and only the wording changes. Arguing about which default applies is what never works.
4. Should IP transfer be written into the contract? Yes — and here is the clause
I put an ownership clause in every proposal I send, unprompted, because it removes the single most common source of late-stage friction. If a developer resists writing one, that is information.
Below is the structure I use. It is not legal advice and it is not jurisdiction-tuned, but it shows you what a fair clause contains — and note that a fair clause protects the developer too.
INTELLECTUAL PROPERTY
1. Foreground IP. On receipt of cleared final payment, the Developer
assigns to the Client all economic rights, worldwide and in
perpetuity, in the bespoke source code, database schema, design
files and written documentation produced under this agreement.
Where local law does not permit assignment of copyright, the
Developer instead grants an exclusive, transferable and
sublicensable right of exploitation to the same extent.
2. Interim licence. Before final payment, the Client holds a
non-exclusive, non-transferable licence to use the delivered work
for internal evaluation and staging only.
3. Background IP. Pre-existing libraries, internal starter kits and
generic utilities owned by the Developer are NOT assigned. The
Developer grants the Client a perpetual, irrevocable, worldwide,
royalty-free licence to use, modify and sublicense them as
incorporated in the deliverables.
4. Third-party components. Open-source and commercially licensed
components remain the property of their licensors and are supplied
under their own terms. A list is delivered at handover.
5. Handover. Within 5 business days of final payment: full Git
history transferred to the Client's organisation, .env values
supplied over a secure channel, DNS and hosting root credentials
confirmed in the Client's name, deployment runbook delivered.
6. Portfolio. The Developer may display the public-facing result and
name the Client in a portfolio, unless the Client objects in
writing.
Clause 3 is the unprofitable thing I am willing to say out loud. Any experienced developer arrives with a personal toolkit — an auth scaffold, a permissions layer, a deployment script refined over years. You are not buying that toolkit. You are buying an unlimited, permanent, transferable right to use it inside your product. A developer who claims to assign you outright ownership of their entire internal library is either lying or is going to have to stop using their own code. Neither helps you. If you want a starting point in Arabic and English, I published a web development contract template that lays this out in plain language.
Two clauses to strike out if you see them
- "Licence granted for use on a single domain." Fine for a WordPress theme. Not acceptable for a custom build you paid to have written.
- "Ownership transfers upon completion of the project." Who defines completion? Ambiguity here is exactly the crack a dispute opens in. Tie it to payment, which is measurable.
5. What if the developer hosts everything on their own account?
Then you have a business continuity problem that no IP clause solves. This is the failure mode I see most often, and it is rarely malicious — it usually starts as a convenience. The developer already has a Hostinger or DigitalOcean or AWS account, spinning up a server there takes four minutes, and nobody wants to slow the kickoff down with a billing conversation.
Eighteen months later the developer is unreachable, the card on file declines, and your entire company is inside an account you cannot log into.
The fix costs almost nothing at the start:
- You open the accounts. Registrar, hosting, cloud, email, analytics, error tracking, payment gateway. Your company legal name, a role-based email like
tech@yourcompany.comthat survives staff turnover, your corporate card. - You invite the developer as a collaborator. AWS IAM user, DigitalOcean team member, Cloudflare member, GitHub org member. Scoped, revocable, auditable.
- You hold the recovery factors. The 2FA seed and recovery codes for the root account belong to you or your finance director, not the person building the site.
- You verify a restore. Not a backup — a restore. Once, before launch, prove that you can rebuild the site from your own backup without the developer in the room.
I actively prefer this arrangement. It means when the engagement ends cleanly, there is nothing to untangle — I get removed from an org and everything keeps running. If you are choosing infrastructure now, my breakdown in choosing web hosting in 2026 covers which providers make delegated access straightforward, and the website security checklist covers the credential hygiene side.
6. Who owns the domain and the hosting account?
The domain is owned by whoever is listed as the registrant in the registrar's records — not whoever paid, not whoever chose the name, not whoever the WHOIS privacy service shows. With privacy protection switched on, the public WHOIS record tells you almost nothing, so verify from inside the account.
Do this today, before you read further, if you have an existing site:
- Log into the registrar yourself. If you cannot, you do not control your domain.
- Check the registrant organisation and the registrant email. It should be your company, at your address.
- Check the expiry date and turn on auto-renew with your own card. Expired domains are the most common way a small business loses everything at once, including email.
- Note the nameservers. If they point at a developer-controlled Cloudflare account, that account can redirect your traffic anywhere.
One timing detail worth knowing: domains can be locked against transfer for a period after registration or after certain registrant changes. ICANN has been revising its Transfer Policy and registrars have been rolling the changes out on different schedules through 2025 and 2026, so the exact lock behaviour depends on your registrar today. Do not assume you can move a domain the same week you need to. Ask your registrar directly.
7. Can a developer hold my site hostage?
Practically? Yes, if you handed them the keys. Legally? It is far weaker than it looks — and it usually collapses under one email.
What people call "holding a site hostage" is almost always one of three situations, and they are not the same:
Situation A: unpaid invoice, developer withholds handover
This is not hostage-taking. This is a supplier exercising a contractual condition. If the contract says ownership transfers on final payment, the developer is doing exactly what you both signed. Pay, get the assignment, move on. If you think the work is defective, the correct move is a written snag list with a deadline, not withheld payment — withholding payment is what converts a quality dispute into an ownership dispute.
Situation B: paid in full, developer refuses to hand over
Now you have leverage. In order: a written demand quoting the clause and setting a 7-day deadline; a formal letter from a lawyer, which resolves most of these; a platform dispute if you contracted via Upwork or a similar escrow; a registrar dispute to recover a domain registered on your behalf; and finally, a claim. Bad outcomes here are almost always cases where nothing was in writing, so there was nothing to enforce.
Situation C: no contract at all, and the developer disappears
The hardest one, and the most common with cheap hires. You may hold nothing but an implied licence to a system you cannot access. Recovery means proving registrant status to the registrar, proving payment to the host, and often rebuilding. Budget the rebuild. I have taken over enough of these to say plainly: the cost of recovering an abandoned project frequently exceeds what the original build cost, because you pay for archaeology before you pay for code.
Prevention beats remedy: the three things that make hostage-taking structurally impossible are (1) you own the registrar and hosting root accounts, (2) code is pushed to a Git organisation you own, from week one, not at handover, and (3) payment is staged so neither side is ever more than one milestone exposed.
8. Milestone payments: the structure that protects both sides
Ownership disputes are usually payment disputes wearing a costume. Structure the payments correctly and most of the risk evaporates.
Here is the pattern I use on fixed-fee projects. The exact split shifts with project size, but the shares below add up to the whole fee and the logic holds at any scale.
| Milestone | Typical share | What the client receives | Ownership status |
|---|---|---|---|
| Kickoff | 30% | Repo created in client org, environments provisioned, spec signed | Interim licence only |
| Core build accepted | 25% | Working staging URL, main flows demonstrable | Interim licence only |
| Feature complete / UAT | 25% | Full staging system, client testing window opens | Interim licence only |
| Launch and handover | 20% | Production deploy, credentials, documentation, licence list | Full assignment takes effect |
Three rules that make this work. Never let the final milestone fall below about 15% of the total — under that it stops functioning as an incentive to finish, because walking away becomes cheap for the developer. Never let it climb much above 25% either, because past that point the developer is financing your business, and good developers will decline the job, correctly. And define acceptance for each milestone in one testable sentence before the project starts, not after.
For anything above roughly USD 15,000, escrow is worth the fee. Upwork and similar platforms build it in; independent escrow services for larger contracts typically charge in the low single-digit percentages. I have no objection to escrow — it protects me from a client who disappears just as much as it protects you. If you are still weighing structures, freelance developer vs agency compares how the two handle payment terms and IP clauses very differently, and what a website actually costs in 2026 covers where the money goes.
9. Do freelance developers sign NDAs — and does an NDA give me ownership?
Yes, most of us sign them routinely. I sign one before a discovery call whenever a client asks, and I have never charged for it.
But understand what you are getting, because these two are constantly confused:
- An NDA controls disclosure. It stops me telling anyone what your product does, showing your figures, or sharing your data. It says nothing about who owns the code.
- An IP assignment controls ownership. It moves the copyright. It says nothing about secrecy.
You need both, and they are separate clauses or separate documents. I have reviewed NDAs from clients who believed the NDA had handed them the source code. It had not.
What a workable NDA looks like: mutual rather than one-way, a defined term (2–3 years is normal for software, perpetual for genuine trade secrets), standard carve-outs for information already public or independently developed, and a portfolio carve-out negotiated openly. If you need me under a strict NDA with no portfolio rights, say so and I will agree — I just want it decided at the start rather than discovered at launch. Some of my work sits under exactly that arrangement, so what appears on my portfolio is the work clients have cleared for display, described the way they agreed it could be described.
One clause to watch: non-competes that would prevent me from working in your entire industry for years. In many jurisdictions these are unenforceable against contractors, and where they are enforceable they price the job up substantially. A narrow, time-boxed non-solicitation of your named clients is reasonable. "No fintech work anywhere for three years" is not.
10. What nobody can sell you: open source and third-party licences
You cannot be assigned ownership of Laravel, React, Next.js or PostgreSQL. Nobody can transfer them to you, and any contract claiming to is drafted by someone who has not read it. What you own is your code, sitting on top of components licensed to the world.
The practical implications are small but real:
- Permissive licences (MIT, BSD, Apache 2.0) — the bulk of the modern web stack. You can use, modify and sell commercially. Keep the attribution notices. Apache 2.0 asks for two things more: carry forward any NOTICE file that ships with the component, and state prominently in any file you modify that you changed it (§4b and §4c). That is the entire obligation.
- Copyleft (GPL, AGPL) — AGPL in particular is worth knowing about, because it can reach network-delivered software. If a component in your SaaS is AGPL, get advice before you assume you can keep your source private.
- Commercial licences — paid admin panels, premium plugins, marketplace themes, licensed fonts, stock photography. These are usually per-site or per-product seats. Buy them in your own account. A licence sitting in the developer's marketplace account is not yours, and marketplace terms often prohibit transferring it.
Demand a written dependency and licence inventory at handover: package name, licence type, whether it was paid for, and in whose account the seat lives. It takes me under an hour to produce and it is the document clients thank me for two years later.
11. The ten-minute check before you sign anything
- Does the contract contain the word "assign" — not "grant a licence to" — for the bespoke work? Under German law, where copyright cannot be assigned at all, the equivalent to look for is an exclusive, transferable and sublicensable grant of exploitation rights.
- Is the assignment tied to a measurable event (cleared final payment), not a vague one ("completion")?
- Is background IP handled honestly: not assigned, but licensed to you perpetually and irrevocably?
- Are you the registrant of the domain, in your company's name, with your own card on file?
- Do you own the hosting and cloud root accounts, with the developer as a scoped collaborator?
- Is the Git repository inside your organisation from week one?
- Is handover defined as a list of artefacts with a deadline, not "we'll send everything over"?
- Have you tested a restore from your own backup before launch?
- Is there a mutual NDA, separate from the IP clause?
- Is the final milestone between 15% and 25% of the total?
If a developer pushes back on more than two of those, you have learned something valuable for the price of an email. My full screening process for this is in how to hire a web developer, and the common objections are answered on my FAQs page.
12. How I handle it
Every project I take starts with the repository in the client's GitHub organisation, infrastructure in accounts the client owns, and a written clause assigning all bespoke work on final payment. I have worked this way across Egypt, Saudi Arabia, Kuwait, Turkey, the UK, Switzerland, France and Germany, and it has never once cost me a project. It has saved several.
The reason is simple. A client who is confident they will own the result stops negotiating defensively and starts talking about the product. That is a better project for both of us.
If you are about to sign something and want a second pair of eyes on the ownership and handover clauses, send it to me through the contact page. Free consultation, a fixed-fee quote if you want the build itself, and I reply within 24 hours. Whether you hire me or not, do not sign a development contract that never uses the word "assign" — or, where the law forbids assignment, its exclusive-licence equivalent.