Unless the contract expressly says otherwise, the developer—not the customer—may own the website code or retain the rights that matter in many commissioned projects. Full payment does not automatically transfer copyright. The exact default depends on the governing law and the parties’ status, so put assignment, exclusions, accounts, deliverables, and exit duties in writing before development begins.
The gap rarely hurts on launch day. It appears when the business wants a new agency, sells an operating unit, changes hosting, or needs an emergency repair. A customer can “own the website” in ordinary conversation while possessing only administrator access to a running copy. The repository, build process, design source, deployment keys, and right to modify may remain elsewhere.
This is a commercial drafting guide, not legal advice on a particular agreement. Have qualified counsel review the governing law and project facts when the site produces material revenue, handles sensitive data, or contains valuable original technology.
Payment is not an intellectual-property assignment
Copyright normally protects original software and creative material. The initial owner is determined by applicable law, employment status, and contractual facts; a commissioned supplier is not automatically equivalent to an employee. The Saudi Authority for Intellectual Property identifies software as copyright-protected subject matter and provides a software and application registration service.
The World Intellectual Property Organization’s contracts handbook draws the central distinction: an assignment transfers intellectual-property ownership, while a licence permits use but leaves ownership with the licensor. A paid invoice proves payment for the described service. It does not fill an absent assignment clause.
A website also combines rights from several sources. Bespoke code may be assignable. A commercial font, stock image, purchased theme, or third-party service is usually licensed. Open-source components retain their own terms. The contract needs an asset map instead of one vague promise of “full ownership.”
Ownership and a licence solve different problems
Ownership of economic rights generally allows the owner to reproduce, adapt, authorize, and transfer the protected work within legal limits. A licence grants selected permissions. It may be perpetual or time-limited, exclusive or non-exclusive, transferable or personal, and restricted by territory, deployment, user count, or purpose.
A licence is often the correct mechanism for a library, font, image, or reusable vendor component. The risk is an unclear licence that lets the customer operate only while paying the original developer or prevents another supplier from maintaining the product.
Separate the rights deliberately:
- Assign the bespoke code, interface, and paid content created for the customer.
- Schedule every pre-existing, commercial, and open-source component with its licence.
- Register the domain, hosting, analytics, and service accounts under customer control.
- Reserve genuine vendor tools without making the delivered site dependent on undisclosed assets.
If a supplier needs reusable foundations, identify them before work starts. A broad reservation for “all tools, methods, and know-how” should not swallow the application that the customer commissioned.
Essential website-contract clauses
The short wording below identifies the commercial result. It is not substitute language for counsel: the final provisions must align with payment, acceptance, warranties, third-party licences, confidentiality, and termination under the selected law.
Asset or clause | Concise drafting outcome | Risk when it is missing |
Source code | Custom-code economic rights pass to the client after specified payments | Client may have operation rights but no modification or transfer right |
Design | Editable source files are delivered and bespoke visual rights are assigned | Client receives exports that cannot be efficiently changed |
Content | Client materials remain client-owned; commissioned paid content is assigned | Reuse of copy, photography, or illustration becomes disputed |
Domain | Domain is registered to the client in an account it controls | Another party can block renewal, DNS changes, or transfer |
Hosting | Client owns the account or has an unconditional export and migration right | Exit depends on supplier approval and timing |
Data | Client owns its data and receives a documented, machine-readable export | Migration produces incomplete or unusable records |
Deliverables | Repository, history, design source, documentation, keys, and account list are specified | A running site arrives without the means to operate it |
Termination | Handover period, assistance, charges, retention, and verified deletion are defined | The relationship ends in outage or urgent renegotiation |
Add a chain-of-title warranty. The agency should confirm that its employees and subcontractors have made the assignments or permissions needed for the agency to grant the promised rights. Otherwise, the prime supplier may promise ownership it never collected from the people who created the work.
Speak with the CloudTopia team on WhatsApp and request a website scope that states code ownership, accounts, and handover before you sign.
What source-code handover actually requires
A ZIP archive emailed at the final milestone is not a complete handover. The customer needs the repository with relevant history and releases, build and deployment instructions, dependency versions, an environment-variable template without exposed secrets, a service inventory, secure data-export instructions, and operating or recovery documentation.
Corporate ownership also needs administrative access. Put the registrar, DNS, cloud hosting, source repository, email, analytics, payment gateway, and monitoring under company accounts whenever possible. Give the agency the permissions needed to work, but do not make an employee’s or vendor’s personal identity the only root owner.
Make handover incremental. Give the customer repository visibility or an accepted snapshot at each paid milestone. Require a working staging release, passed acceptance tests, source files, and a record of unresolved defects.
Request a software-components register too. Record component, version, source, licence, modification, and any attribution or distribution duty. Legal and technical reviewers can then identify a restriction before release rather than during acquisition or migration.
Three realistic lock-in scenarios
These are composite scenarios based on recurring contract patterns, not claims about named businesses. They show how lock-in develops through account and drafting omissions rather than an explicit sentence saying the developer will withhold the site.
A retailer grows but cannot migrate. The company paid build and maintenance invoices, yet the agency owned the domain, cloud account, and deployment pipeline. When the parties disagreed over a feature quote, the retailer discovered that its access covered catalogue editing only. A replacement team rebuilt modules because no current repository was delivered.
A business sale exposes missing rights. Due diligence finds that a freelancer bought the theme and images under personal licences and signed no copyright assignment. The buyer discounts the digital asset until the parties cure the rights and replace non-transferable material. The website continued to work, but title was commercially defective.
A platform exits without usable data. The agreement says “managed hosting” but specifies no export format, attachment handling, or post-termination period. The client receives disconnected spreadsheets missing relationships and files. It owns the business records in principle but cannot recreate the service from what was handed over.
The shared remedy is client-controlled accounts, a rights schedule, milestone deliveries, and an exit test conducted before a crisis.
A practical client-ownership model
Client ownership of bespoke source code is a standard term in CloudTopia contracts. The useful formulation is not a two-word ownership claim; it states when economic rights transfer, separates newly commissioned work from licensed or pre-existing components, and connects handover with the agreed payments. Native Arabic RTL and local-currency pricing are delivered alongside that control.
Good drafting does not pretend to assign an asset that cannot lawfully be assigned. Fonts, stock media, plugins, frameworks, and open-source packages may remain subject to third-party licences. The schedule should give the client sufficient continuing rights to operate, move, and maintain the website. Domain, hosting, analytics, and operational accounts should be client-controlled where available.
There should be no surprise “source release fee” after completion when source transfer is already included in scope. If the customer instead selects a hosted subscription or a ready-made product that does not transfer platform code, place that limitation prominently in the offer and contract, not inside a generic definitions page.
Pre-signature website ownership checklist
Review this list against both the proposal and technical schedule. Ask legal counsel to inspect operative language rather than relying on section headings.
- Confirm who owns bespoke source code and when the rights transfer.
- Confirm the rights to copy, modify, migrate, and appoint another supplier.
- Confirm the schedule of pre-existing, commercial, and open-source components.
- Confirm control of the domain, hosting, email, analytics, and payment accounts.
- Confirm delivery of repository history, design source, documents, and deployment material.
- Confirm the data and attachment export format and post-termination availability.
- Confirm employee and subcontractor assignments and non-infringement warranties.
- Confirm acceptance tests, milestones, staged handover, and change control.
- Confirm exit assistance, charges, time limits, retention, and verified deletion.
- Confirm governing law, dispute procedure, and review by suitable local counsel.
Do not let an email promise contradict the signed agreement. Put the promise into an executed amendment or schedule. When the contract says “full ownership,” ask which deliverables are included and which items are excluded. A precise inventory is more useful than a broad adjective.
What to do when a developer refuses delivery
Collect the contract, amendments, invoices, acceptance records, relevant messages, and account inventory. Send a written request identifying each file or permission, the contractual basis, and a reasonable deadline. Preserve evidence and service availability. Do not delete shared accounts, exceed access rights, or issue threats while the facts are being established.
Ask counsel qualified under the governing law to assess ownership, breach, interim protection, and dispute steps. Possible outcomes include enforcing handover, negotiating a settlement, preserving data, or commissioning a controlled rebuild. The right option depends on the wording, jurisdiction, payments, and technical facts.
Use official verification routes with the domain registrar or hosting provider. A technical team can inventory accessible assets, secure authorized backups, and plan continuity without copying code the business is not entitled to use.
Keep the operational track separate from the dispute track. Record every credential change, export, authorization, and service dependency. That evidence helps legal advisers and prevents a well-meant emergency action from causing an outage or weakening the company’s position.
Contact CloudTopia on WhatsApp for a website proposal that includes source ownership, client-controlled accounts, and handover from the start without a later release charge.
Frequently asked questions
Who owns a website after it has been paid for?
Payment alone does not guarantee ownership of code copyright. Governing law and contract terms decide whether the customer receives an assignment or only a licence. Require written transfer of bespoke code and design rights, identify licensed themes and libraries, and link delivery of repositories, files, and accounts to the agreed payments.
Can I move my website to another company?
You can move it when you control the domain and accounts, possess code, data, and documentation, and hold a licence or ownership rights allowing another supplier to modify them. Check exit support, export format, timing, and fees. Obtain local legal advice before copying or changing disputed assets or permissions.
What should I do if the developer refuses to hand over the code?
Preserve the contract, invoices, acceptance records, messages, and account evidence, then issue a precise written request without disrupting service or exceeding access. Ask qualified local counsel to assess breach and remedies, while a technical team inventories authorized assets and data. Enforcement, settlement, preservation, or rebuilding may each be appropriate.
Should the domain be in my name or the agency’s name?
Register the domain to the client’s legal entity in a corporate account the client controls. Give the agency limited technical access where needed. Verify registrant information, billing, recovery email, transfer lock, and multifactor authentication. Displaying the client’s brand on a website does not prove domain ownership or transfer authority.
Read also
Need a website, dashboard, or business system like this?
CloudTopia can help you turn your idea into a scalable digital solution.
Share this article
Written by
Mohamad Shahm | محمد شـهم
Mohamad Shahm founded CloudTopia after a decade building web platforms, e-commerce systems, and bilingual (Arabic + English) experiences for Gulf businesses. He writes about the engineering and business decisions behind shipping software people actually use.
