When many business owners sign a website development contract, their attention is all on the quote and timeline, and for the deliverables section they casually write "one website, one set of source code." Only after the project is done do they discover: design files aren't provided, backend accounts are in the vendor's hands, the server is registered under the other party's name, and even changing a banner requires an extra fee.
This isn't about anyone being malicious—it's that the contract wasn't written clearly. The more specific the deliverables, the less trouble later. Below we break it down into five categories, each with wording you can adapt directly.
1. Source Code and Deployment Package: Specify "What to Deliver and How"
Source code is the easiest item to leave vague. We recommend specifying three things in the contract: which code to deliver, in what form, and whether it can run independently after delivery.
A workable formulation is: frontend source code, backend source code, database structure files, and deployment documentation, delivered as a package, with an agreement that after delivery Party A can independently deploy and run it on its own server.
There are two pitfalls to avoid. First, writing only "provide source code" without specifying the database structure means the code won't run even when you get it. Second, the code references the vendor's proprietary components or encrypted files—on the surface it's delivered, but in reality you can't function without the other party. Corporate websites especially need attention here; the so-called source code of many template sites is actually a licensed secondary wrapper.
If it's mini program development, you should additionally specify: the mini program master account belongs to Party A, and the code can be submitted to Party A's own developer backend.
2. Design Files and Assets: Don't Just Hand Over Screenshots
For design deliverables, we recommend specifying: editable source files (such as Figma, Sketch, or PSD), sliced image assets, and usage instructions for fonts and icons.
Providing only JPG screenshots is as good as providing nothing. When you later change designers or extend campaign pages, everything has to be redrawn.
You should also agree on asset copyright ownership: whether the images, fonts, and icons used by the vendor are commercially usable, and who is responsible if copyright disputes arise. This clause is often overlooked in website development projects, but when trouble actually hits, it means immediate takedown.
3. Domain, Server, and Accounts: Ownership Must Be Written in Stone
This is a high-dispute area. The contract should clearly state: the domain is registered under Party A's name, the server or cloud account is purchased under Party A's real-name registration, and the vendor retains only the necessary operational permissions during development and maintenance.
A concrete scenario: a company did a website redesign and after completion discovered the domain was in the hands of the previous service provider—renewal required extra payment, migration required their cooperation, and it dragged on for a month.
So the delivery checklist should list: domain management account, cloud server account, database account, backend administrator account, ICP filing information, and accounts and keys for third-party services (SMS, payment, maps). Verify each item and sign off during handover.
4. Backend and Documentation: It's Only Delivered When It's Usable
The backend management system delivery isn't just about accounts—it also includes: a feature list, field descriptions, role permission descriptions, and common operation manuals.
We recommend arranging one online or offline handover training session and keeping a screen recording. This way, when staff turnover occurs, new colleagues can learn on their own.
For App development and complex backend projects, you should also require API documentation and version records to facilitate future integration with other systems.
5. Acceptance Criteria: Turn "It Works" into Testable Items
Acceptance clauses must be executable. We recommend writing: item-by-item acceptance of features per the requirements document, a compatibility list for mainstream browsers and device models, a page load time limit, and basic items for website security testing (such as checks for common injection, privilege escalation, and sensitive information exposure).
Also agree on the defect repair period and response time limits, as well as the number of rectification rounds if acceptance fails.
Pitfall to avoid: don't write "subject to Party A's satisfaction," and don't write unverifiable phrases like "meets industry standards."
When It's Appropriate to Work with MIC Studio
If you're in any of the following situations, consider talking to us: your requirements are already clear and you need a deliverable checklist that can actually be implemented; you have an existing system that needs reverse engineering testing or security review; or you don't have dedicated in-house technical staff but want the accounts, source code, and documentation all in your own hands.
We do corporate websites, mini program development, App development, and script development, and we also take on security testing. During the contract stage, we list deliverables item by item in a table and sign it as an attachment, avoiding repeated explanations later.
Three Actionable Recommendations
1. Make the deliverables into a table attachment, listing "name, form, delivery time, acceptance method" for each item, and sign to confirm.
2. Before signing, confirm who owns the domain and cloud accounts. If they're not under your name, migrate them first before discussing development.
3. Link the final payment ratio to acceptance—retain 10%–20% to be paid after handover training is completed and accounts are verified.
Writing a detailed contract isn't about distrust—it's about saving both parties time on explanations.