When choosing a website development company in Xiamen, how should you agree on source code delivery?

When choosing a website development company in Xiamen, do not simply state “delivery of all source code” in the contract. Specify which files will be delivered, how they may be used, whether the website can be deployed independently, and how acceptance will be conducted. Otherwise, even if you receive a compressed file after the website goes live, you may be unable to move to another server or service provider because the database, dependencies, or operating authorization are missing.

During procurement, first confirm whether you are purchasing a website that can be deployed independently or a website-building service on an annual subscription. For the former, include the source code, data, and deployment materials in the deliverables. For the latter, the platform source code may not be provided, so focus on agreeing on data export, domain control, and support for migration upon exit. These two types of solutions cannot be covered by replacing specific terms with the same statement: “The source code belongs to Party A.”

First clarify: Will you receive the source code, or only access to the admin interface?

An administrator account for the backend only proves that the company can manage content; it does not mean that it has acquired the website software. The page code visible in a browser is also not the complete project source code, which includes business logic, interfaces, and database structure.

When comparing quotes, ask suppliers to answer three questions directly in an appendix to the quote: Can the website be deployed to a server designated by the company? Which functions will stop working if the subscription is not renewed? Can a third-party technical team take over maintenance within the scope of its authorization? If the answer involves “platform support,” ask the supplier to list the dependencies and associated costs rather than accepting “we can discuss this later.”

Choosing a SaaS website-building service does not necessarily make the solution unsuitable. However, if the company explicitly requires independent operation in the future, confirm before signing whether an independent deployment option is available. Do not wait until after launch to ask the supplier to open up the platform’s underlying code.

Specify the deliverables down to the files and documentation

We recommend listing the following items in a contract appendix and marking each as “to be delivered,” “not applicable,” or “third-party licensed.” This avoids allowing the supplier to use the vague phrase “complete website package” to cover all responsibilities.

Production environment passwords and API keys should not be written directly into the code package. They should be handed over separately through a secure method. After handover, change the keys and revoke any permissions the supplier no longer needs.

Receiving the source code does not mean acquiring all intellectual property rights

Websites typically combine custom code, components previously developed by the supplier, and third-party software. The contract should specify the rights to each separately: ownership or licenses for use of custom components, whether existing components may continue to be used, and the licenses governing third-party components. Do not ask the supplier to transfer rights it is not entitled to transfer, and do not assume that payment automatically grants all copyrights.

For the purchaser, the more direct questions are whether the company can modify, back up, deploy, and maintain the website itself or through a third party, and whether these rights are subject to restrictions on the domain, number of servers, usage period, or renewal terms. The relevant authorization should cover the scope required for the website’s actual operation, and its termination conditions should be specified.

Fonts, images, and commercial plugins may also be licensed for use only on the current domain. If you plan to change domains, duplicate a multilingual site, or add another site, confirm in advance whether additional licenses need to be purchased. The supplier should disclose any known restrictions; “the source code has been delivered” is not a substitute for explaining licensing issues.

Acceptance should verify independent operation, not just that all files are present

Being able to download and extract the files is only part of the handover. A more reliable acceptance method is to redeploy the website in an agreed, independent test environment using the delivery documentation, then check the key functions within the scope of the contract.

1. Check that the delivered version matches the live version, and record the version number, delivery date, and file verification information to avoid receiving an outdated version.
2. Have the company’s technical staff or an appointed third party install the website using the documentation. Confirm that dependencies are available, configuration items are complete, and there are no undisclosed remote authorization restrictions.
3. Test page access, backend editing, form submission, and file uploads. For an online store, also verify the order and payment test process to avoid triggering real transactions by mistake.
4. Check whether data and attachments can be restored, and verify that the original URLs, redirect rules, and agreed SEO settings have been retained.

If services such as payment processing and email cannot be reused in the test environment, agree on alternative verification methods in advance. Record acceptance defects, distinguish issues that block deployment from general defects, and specify repair deadlines and retesting procedures.

Agree on delivery milestones, final payment, and exit responsibilities together

The source code should not be delivered only once, at the end of the project. You can agree on separate deliveries of the relevant versions at testing acceptance and official launch, with the source code and documentation updated alongside any subsequent paid iterations. The conditions for paying the final installment should be tied to the agreed deliverables and acceptance results, not merely to whether “the website is accessible.”

Contract terms can be refined along the following lines: At the agreed milestones, Party B shall deliver the source code, data, and deployment materials listed in the appendix; Party A or its appointed party may deploy, modify, and maintain them within the agreed scope of authorization; any items not delivered and any third-party restrictions must be listed before signing; if any items are missing or deployment cannot be completed in accordance with the documentation, Party B shall provide the missing items and assist with retesting within the agreed period. The parties must still complete and confirm the specific deadlines, acceptance criteria, and remedies for breach.

The termination-of-cooperation terms should also specify the data export period, format, scope of migration assistance, fees, and data retention arrangements. The company should, wherever possible, control the domain registrant details and key accounts. Production data should not be deleted without authorization before the handover is confirmed.

When screening website development providers in Xiamen, ask them to submit a redacted delivery inventory, a sample deployment document, and a list of licensing restrictions. A solution that promises “all the source code” but is unwilling to confirm the conditions for independent deployment and acceptance should not be purchased as a migratable website.