Who Owns Website Source Code After Development?

After paying to complete a website, a company usually assumes, “This website is mine.” In practice, however, a website consists of multiple asset layers: brand design, custom pages, open-source frameworks, commercial plugins, fonts and images, databases, servers, and third-party APIs. The rights to these assets do not come from the same sources.

Source-code disputes are often not purely legal questions; they are also questions of procurement scope. Under a SaaS subscription or template-platform quote, the client may be purchasing usage rights. With custom development, the parties can typically agree to deliver the custom code. If these distinctions are not clarified before the project begins, “everything belongs to the client” is unlikely to resolve them at handover.

01 Distinguish File Control, Usage Licenses, and Copyright

Receiving a compressed code file means you control a copy of the files, but it does not necessarily mean you own the copyright to every asset inside. Conversely, even when a contract transfers certain rights, the client still needs working code, accounts, and documentation to continue maintenance.

What the buyer truly needs to confirm is whether it can deploy on its own servers, modify the system or engage a third party to do so, migrate away from the current vendor, identify ongoing fees, and understand what stops working when payments end.

02 Website Code Usually Comes from Five Layers

The first layer is business code developed specifically for the project; the second is the vendor’s existing components or scaffolding; the third is open-source frameworks and packages; the fourth is commercial themes, plugins, and fonts; and the fifth is external services such as cloud platforms, maps, SMS, and payments.

The contract should address each layer separately. Project-specific code can be transferred or permanently licensed after final payment. The vendor’s general-purpose components may be licensed only for project use. Open-source code remains subject to its original licenses. Commercial plugins may require a client account or renewals, while third-party cloud services are not source code.

03 Source-Code Boundaries Differ Across Three Website Models

With a visual SaaS platform, the client generally owns its content and domain but cannot obtain the platform’s underlying source code. With an open-source CMS such as WordPress, it can obtain the website files and database, but themes, plugins, and fonts retain their own licenses. Fully custom development can deliver the complete project code, although it will still depend on open-source packages and cloud services.

Therefore, a solution should not be judged simply by whether source code is available. For a content-focused corporate website, a stable CMS and portable data may matter more than owning the underlying platform code. A core business system requires stricter controls over source code, deployment, and security.

04 Define at Least Eight Items in the Contract

Source-code clauses do not need to read like a technical paper, but they must be actionable for the handover team. Scope, milestones, third-party dependencies, and migration support should be specific enough to verify.

1. Which designs and code are final deliverables for this project;

2. When a transfer of rights or license becomes effective;

3. Whether the client may modify, copy, and deploy the work itself or engage a third party for maintenance;

4. How the vendor’s preexisting components and general-purpose code are licensed;

5. The inventory, accounts, and renewal responsibilities for open-source and commercial plugins;

6. Ownership of the domain, servers, database, analytics, and third-party accounts;

7. Data export, migration assistance, and the transition period when the engagement ends;

8. How nonpayment, project termination, and confidentiality are handled.

05 Verify Handover with a Portability Test

The client should receive the code repository, build instructions, sample environment variables, database schema, and deployment documentation. If the website has an admin system, verify that content can be exported and the company controls the administrator account.

Complete an independent deployment on a test server, or at minimum have a third-party developer run the project locally. If the website cannot operate without the original vendor’s dedicated server, proprietary plugin, or manual intervention, source-code handover remains incomplete.

□ Does the repository match the complete production release?

□ Is there a traceable inventory of dependencies and plugins?

□ Can the database and uploaded files be exported completely?

□ Are build, deployment, backup, and rollback documented?

□ Does the client control the domain, DNS, server, and analytics accounts?

□ Does the website continue operating normally after vendor access is removed?

06 When Full Source Code May Not Be Necessary

If a company deliberately selects a mature SaaS platform to launch quickly with low maintenance and accepts its subscription and migration constraints, it need not insist on the underlying source code. What matters is that the company owns its content, customer data, domain, and exportable assets.

However, when a website supports core transactions, proprietary algorithms, complex system integrations, or highly regulated data, platform usage rights alone may be insufficient. Greater control may be needed in both the technical architecture and contract. The choice should reflect business risk rather than treating “all source code belongs to us” as universal reassurance.

07 Do Not Confuse Source-Code Ownership with Complimentary Maintenance

Client ownership of source code does not require the vendor to provide free revisions forever. Vendor maintenance does not justify withholding source code indefinitely. Rights, handover, warranty, operations, and new requirements are separate terms and should be agreed separately.

Complimentary maintenance typically covers defects within the existing scope. It does not include new pages, system upgrades, changes to third-party services, or issues caused by client modifications. Clear scope is fairer to both parties.

Frequently Asked Questions

Does the client automatically own the source code after paying the final balance?

It depends on the contract and website model. A custom project can specify delivery, while a SaaS platform typically grants usage rights only. Third-party plugins and open-source code remain subject to their respective licenses.

Does open-source code have no copyright?

No. Open-source software remains copyrighted, but its license permits use, modification, and distribution under defined conditions. The project must comply with those conditions.

Can a WordPress website be migrated completely?

Website files and the database can usually be migrated, but verify that themes, plugins, fonts, server configuration, and licenses remain usable.

Can a vendor deliver only the final source code without the Git history?

If the contract specifies only the final version, that may satisfy the agreed delivery format. Complete history is more useful for maintenance, rollback, and auditing, so it should be included in the checklist at project kickoff.

Can the vendor showcase the project after source code transfers to the client?

Whether the vendor may showcase it depends on the contract’s attribution, portfolio-use, and confidentiality clauses. These should be agreed separately from source-code rights.