Who Owns the Source Code, Domain, and Server Account in Custom Website Development? What Pitfalls Await If Not Delivered Together?

In custom website development, receiving only a URL at the end is far from sufficient. Based on 2026 project delivery practices, the complete deliverables include at least: the source code, domain management rights, server and database accounts, backend administrator access, design source files, and deployment documentation. Only when all these digital assets are transferred to the client's name does the client truly own the website; otherwise, future revisions, migrations, renewals, or switching vendors can be held up by the original developer.

Many clients having their first custom website made only check whether the page loads and the features work during acceptance, believing that once the site is live, everything is done. However, at delivery sites, we often see a common situation: the developer deploys the code on their own or a third-party server, registers the domain under the developer's contact email, and the client only receives a backend login account. In essence, such a website is “renting” the developer's assets rather than “buying” your own website.

This leads to a very practical consequence: when you want to modify features, change servers, change the domain, or switch development companies due to pricing issues, you will find that the original developer is uncooperative and you cannot even obtain your own code. Legally, without explicit agreements, ownership of the source code and digital assets can easily become disputed. Therefore, from the very beginning of custom development, the “deliverables checklist” should be written into the contract.

• Common misconception: “Website can be opened = delivery complete” only delivers the “right to use,” not the “asset.”
• Assessment standard: Whether the client can independently back up, migrate, and modify the website code without going through the developer.

Complete Deliverable Checklist: Five Categories Are Indispensable

Based on project delivery practices, we recommend using the “five-category delivery verification method” for acceptance. This is not an additional requirement but the basic deliverables that custom development should typically include. The following checklist comes from our years of project delivery experience range, and it applies to most custom development projects. However, the specific delivery scope is subject to the contract appendices.

1. Source code: The complete project code, including comments and dependency instructions. It is best to place it in a Git repository (e.g., Gitee/GitHub private repository) and grant the client read-only access, or provide a directly deployable code archive. Be sure to include database initialization scripts or migration files. Verification method: Use Git clone to pull the latest code and check that the commit history is complete, rather than a compressed archive without history.
2. Domain management rights: The domain registrar account must be transferred to the client's name, or at least the domain must be moved from the developer's account into the client's account. If the domain was initially registered under the client's business license and merely managed by the developer, the client must also obtain management operation access. Verification method: In the domain registrar backend, verify the domain contact and account ownership to confirm it belongs to the client entity.
3. Server and database accounts: Provide SSH/FTP, server panel, cloud console, and database management accounts. If it is a cloud server, it is best to migrate the server to the client's cloud account during acceptance, or confirm that the client can log into the console. Verification method: Use the client's own account to log into the server panel and confirm that all running services can be viewed.
4. Backend administrator access: The highest-privilege account for the website backend, not just an account with editing permissions. Confirm that this account can create new administrators and modify site settings. Verification method: Log into the backend with this account, attempt to create a test sub-account, and then delete it.
5. Design source files and documentation: UI design source files (PSD, Figma, Sketch, etc.), logo source files, deployment manuals, and operation instructions. These can significantly reduce communication costs during future revisions or secondary development. Verification method: Open the source files to confirm layers are complete, and the documentation covers daily operations and maintenance.

Why verify against this checklist? Because these deliverables correspond to the website's technical layer, domain layer, runtime layer, data layer, and revision capability. Missing any one of them will cause you to lose leverage in a certain aspect. For example, having only the source code without the server account means the code is just “a pile of files” that cannot be deployed.

What Specific Pitfalls Will You Encounter If Deliverables Are Incomplete?

In project delivery, ownership issues of accounts and assets often surface only at the very end. There are four common situations:

• Inability to Switch Vendors: If the original developer does not provide the source code or database export files, you can only continue paying high maintenance fees. According to the experience range, in such cases when negotiating maintenance prices later, the client typically has to pay a 30%-50% premium.
• Data Risk: If the website is attacked or the server expires, and the domain and server are both under the developer's name, you may not even be able to renew urgently. Especially after the server expires, the data may be directly cleared.
• Obstacles to Redesign: If you want another company to do a redesign, but the design source files and API documentation are absent, the new developer needs to reverse-engineer everything from scratch, typically extending the timeline by 30%-60% and increasing the budget.
• Domain Loss: If the domain is registered under the developer's personal email, and they leave or become unreachable, the domain may be hijacked or fail to be renewed. Such disputes are not uncommon in the industry.

At delivery sites, we have also seen a situation that is not extreme but quite common: the client only obtained backend editing permissions but not server FTP permissions. Later, they had to submit tickets to the developer for anything, such as modifying the footer copyright information or handling Baidu analytics code. Each time they had to wait several days or even pay per request. Based on the experience range, the single handling fee for such small requests is usually between 200-500 yuan. Accumulated over a year, this may exceed the maintenance fees you originally wanted to save. Therefore, it is recommended to confirm the scope of asset transfer once during acceptance; otherwise, every small change afterward may become an extra cost.

For a more intuitive comparison, here is a verifiable set of contrasts (both are experience ranges, subject to the actual project):

• Redesign after full delivery: The timeline is about 2-4 weeks, and the cost is about 20%-40% of the original development cost; changing servers takes about 1-3 days, and the additional cost is generally within a few thousand yuan.
• Redesign with missing source code and accounts: The timeline is about 5-8 weeks, and the cost may increase by 50%-80%; changing servers requires reverse-engineering the code first, and may even require starting over.

Special note here: If the developer claims, “We use a proprietary framework, so the source code is useless to you,” you should ask clearly whether the proprietary framework contains unlicensed third-party components. Legitimate custom development usually does not encrypt delivered source code, but it may allow separate licensing for third-party components.

How to Protect Yourself During the Contract and Acceptance Phases?

A more stable approach is to agree on the deliverables checklist when signing the contract, rather than waiting until development is complete. In the technical service terms of the contract, you can specify: “During project acceptance, Party B shall deliver the source code, database scripts, server permissions, domain management permissions, design source files, and operation documents, and assist in migrating them to the account specified by Party A.” Including this sentence in the contract provides a clear basis at acceptance.

During the acceptance phase, it is recommended to first perform “asset inventory” after functional tests pass, and then make the final payment. Specifically, verify each item on the checklist by logging in, such as attempting to log into the server panel with your own account, checking whether the domain contact information in the domain registrar backend has been changed to Party A, and requiring the developer to provide a database backup file exported from the server console.

• Ensure source code completeness: When placing the source code into a Git repository, confirm that the commit history is complete. It is not acceptable to provide only a compressed archive without history.
• Pay attention to permission levels: Ensure that the backend administrator access is for “super administrator,” not “editor,” otherwise you cannot assign sub-accounts later.

If the developer refuses to provide the source code citing “trade secrets,” you can suggest adding confidentiality clauses to the contract, or agree to host the source code on a third-party Git platform and automatically transfer ownership after acceptance. This protects the developer's intellectual property while safeguarding your asset rights.

Applicable Scenarios and Boundaries

This deliverables checklist applies to genuine custom development projects, such as corporate official websites, e-commerce systems, online booking systems, internal management systems, etc., because these websites are the client's business assets requiring long-term iteration. However, in the following scenarios, it can be appropriately simplified or not needed:

• Template sites using SaaS website builders: the code and data belong to the platform, which inherently does not provide source code delivery, so this checklist is not applicable.
• One-time marketing campaign pages or temporary test sites: with a short life cycle, delivering source code may not be cost-effective.
• Pure static display websites: if Party B is willing to provide all files, server accounts are usually not needed because the site can be deployed on any static hosting.

One-sentence boundary: As long as the website is expected to operate for more than one year, or needs to connect to customer data or assume business functions, it should be delivered according to the full checklist. If it is only a temporary demo page, then there is no need to dwell on it.

Frequently Asked Questions

Is it reasonable for the developer to say the source code is theirs and not give it to me?

No, it is not reasonable. Under a custom development commissioning relationship, unless the contract explicitly stipulates that the source code belongs to Party B, the source code should belong to Party A. According to the principles of work-for-hire contracts in the Civil Code's contract section, delivering work results includes relevant technical materials.

The domain is registered under the developer's name. Can it be transferred to me?

Yes. Submit a domain transfer operation in the domain registrar backend, or use a transfer password to move it into your registrar account. Note that the renewal period transfers, but the real-name verification generally needs to remain consistent.

If the source code and accounts are not fully provided during acceptance, can I refuse to pay?

If the contract specifies the deliverables checklist and the payment conditions include the transfer of these assets, you can certainly withhold the final payment when they are not all provided. However, a safer approach is to state in the contract that “payment of the final balance is conditional upon the completion of all asset transfers.”

If the development company goes bankrupt, how can I get the website back?

Advance preparation is important: obtain regular database backups, source code, and server console permissions. If the domain is under the other party's name, you can only contact the registrar for legal assistance; if the domain is under your name, you simply deploy the source code to a new server.

Action advice: Before signing the contract, include the above five-category deliverables checklist as an appendix; during acceptance, verify in the order of “asset inventory first, functional testing in parallel.” This is suitable for companies that regard the website as a long-term asset; if it is only a temporary display page, there is no need to add communication costs for this.