Many disputes in design, branding, and website projects do not result from deliberate breach. The contract expresses the intention to collaborate but fails to define how the work will operate. It may say “design and develop a corporate website” without listing pages, responsive coverage, CMS functions, or ownership of copy and imagery. Halfway through, either party may reasonably believe the other omitted agreed work.
A mature design and development agreement usually relies on three document types. The master agreement defines rights, obligations, and risk allocation. A statement of requirements defines pages, functionality, and deliverables. The quote defines fees, payment milestones, and exclusions. A generic three-page contract rarely carries enough detail for a complex project.
01 Separate the Master Agreement, Requirements, and Quote
The master agreement should not contain every page and feature detail, because a small requirement change would then require renegotiating the entire contract. But if the contract never incorporates its exhibits, and the requirement document has no record of mutual approval, those exhibits may provide little practical control. A safer structure states that “the final scope is defined by the mutually approved statement of requirements, quotation, and change orders,” with an ID, version, and approval date for each.
Document | Primary Purpose | Required Content |
|---|---|---|
Master agreement | Rights, obligations, and risk boundaries | Parties, price, payment, schedule, feedback, acceptance, IP, confidentiality, termination, and disputes |
Statement of requirements | Exactly what the project includes | Page and feature inventories, device coverage, content ownership, technical boundaries, and exclusions |
Quotation | Why each project stage carries a fee | Service stages, deliverables, fees, payment milestones, taxes, and quote validity |
Change order | How work is added or adjusted during delivery | Reason, affected scope, added cost, schedule extension, approver, and effective date |
02 Ten Clauses Every Design and Development Contract Should Define
Clause | What It Must Define | Risk of Vague Language |
|---|---|---|
1. Scope of services | Pages to design, features to build, supported devices, CMS, and launch responsibilities | “Build a website” cannot determine whether added pages are billable |
2. Start conditions and schedule | Which payment and materials trigger work, and how business days are counted | The contract date arrives before materials, and each party assigns delay differently |
3. Communication and feedback | One approver, consolidated feedback, and review deadlines | Several stakeholders submit conflicting comments and reverse versions |
4. Concepts and revisions | Number of directions and rounds, and the difference between refinement and rework | “Revise until satisfied” turns finite scope into unlimited responsibility |
5. Requirement changes | How added pages, functions, languages, motion, and integrations affect fees and time | Verbal additions leave the original quote open to dispute |
6. Payment milestones | Which deliverable and approval trigger the deposit, stage payments, and final payment | Payment becomes disconnected from real progress and leaves a half-finished project |
7. Acceptance criteria | How prototypes, visual design, development, and launch are accepted and defects classified | Subjective preference and functional defects become confused |
8. Delivery and intellectual property | Source files, code, accounts, third-party assets, and conditions for rights transfer | Receiving images is not receiving source files; receiving code is not receiving every license |
9. Warranty and maintenance | Bug scope, duration, response process, third parties, and boundary with new work | “One year of free maintenance” is read as any request being free |
10. Suspension, termination, and disputes | Extended silence, unilateral termination, fees earned, return of materials, and jurisdiction | After the project stalls, neither party knows how to settle or transfer it |
03 Scope Cannot Be Only a Project Name
“Corporate website design,” “mobile app UI,” and “brand refresh” describe categories, not an acceptable scope. Break the work down by page templates, functional modules, devices, languages, motion, content entry, integrations, and deployment. For a website, distinguish page count from template count: 20 news articles using one template are not equivalent to 20 unique business pages.
- □ Pages: number of top-level, secondary, listing, detail, authentication, and error pages
- □ Devices: desktop, mobile, and tablet coverage, including responsive or device-specific interaction
- □ Functions: forms, search, filtering, membership, payments, multilingual content, CMS, permissions, and external APIs
- □ Content: ownership of copy, translation, photography, illustration, video, and data migration
- □ Technology: framework, browser support, server, domain, certificates, deployment, and account ownership
- □ Exclusions: ongoing SEO, hosting fees, paid fonts, stock assets, and future features
04 Define Schedule Start Conditions, Not Only Start and End Dates
Design and development schedules usually depend on client materials, internal review, and third-party APIs. The agreement can state that time begins after the vendor receives the kickoff payment and complete materials, then list causes for extension: late materials, reviews beyond the agreed window, added scope, project suspension, and third-party integration or approval delays. Otherwise, all waiting time may be treated as vendor delay.
Distinguish business days, calendar days, and platform-review time. External review for mobile apps, mini programs, payments, and multilingual content should not be described as a fixed duration controlled entirely by the vendor. The schedule should show responsibilities and dependencies, not only a final launch date.
05 Feedback Rules Matter More Than the Number of Revision Rounds
Revision limits work only when feedback rules are clear. Define each round as one consolidated set of written comments from the client; require the client to resolve conflicts among decision-makers; treat a reversal after approval of the visual direction as a new direction; and extend the schedule when the client misses the agreed review window.
06 Tie Payments to Deliverable Milestones
A common structure uses a kickoff payment, a direction or design approval payment, and a final payment. The important point is not the percentages but the action tied to each amount: the kickoff payment reserves the team; approval of the homepage or core visual direction opens full design; approval of design opens engineering; and launch acceptance or final approval triggers final payment and delivery of source files, code, and accounts.
The agreement should also distinguish an ordinary advance payment from any legally defined earnest-money mechanism under the applicable law. If the parties want special legal consequences to apply, the terminology, amount, and consequences should be reviewed by qualified counsel. Do not label a 50% kickoff payment as “earnest money” merely out of habit.
07 Accept the Work in Stages, Not Once After Launch
Design and engineering need different standards. Prototype acceptance covers information architecture, flows, and screen scope. Visual acceptance covers direction, core screens, and component rules. Engineering acceptance covers functionality, responsive behavior, compatibility, and data. Launch acceptance covers domains, forms, SEO, performance, security, and monitoring. Final handoff covers files, code, accounts, and documentation.
08 Maintenance Must Distinguish Bugs, Environment Changes, and New Work
Free maintenance should normally cover functional defects and compatibility issues within delivered scope. It should exclude failures caused by client or third-party code changes, server or browser changes, third-party policy changes, content updates, redesigns, and new features. State when the warranty begins, how issues are submitted, and what response and resolution process applies.
09 Vague Phrases Most Likely to Cause Disputes
Avoid Writing Only | Use More Executable Language |
|---|---|
Revise until the client is satisfied | Includes three consolidated revision rounds; a full reset after direction approval is quoted separately |
Provide all design files | List Figma, AI, PSD, PDF, PNG, and JPG files and whether rejected concepts are included |
Responsible for website launch | Define hosting, DNS, SSL, deployment attempts, and post-launch boundaries |
One year of free maintenance | Limit it to defects in delivered functions; exclude new work, third-party changes, and environment changes |
The vendor is responsible for project delay | Define treatment of vendor delay, client feedback delay, and third-party approval delay separately |
The client owns all copyrights | Define payment conditions, specific work, specific rights, third-party assets, and the vendor’s portfolio right |
10 Contract Checklist Before Signing
- □ The legal name, registration identifier, contact, and payment recipient are consistent.
- □ The requirements, quote, and page inventory incorporated into the contract have version numbers.
- □ Start conditions, business-day conventions, and schedule-extension events are defined.
- □ Design directions, revision rounds, feedback deadlines, and approval methods are defined.
- □ Added scope requires a written change order.
- □ Every stage payment maps to a stage deliverable.
- □ Acceptance criteria, defect severity, and correction deadlines are defined for each stage.
- □ Source files, source code, accounts, fonts, images, and third-party licenses are addressed separately.
- □ Warranty duration, bug scope, third-party responsibility, and new-work boundaries are defined.
- □ Suspension, unilateral termination, confidentiality, breach, and dispute resolution are defined.
Frequently Asked Questions
Can the contract list only a page count?
No. Page count must be combined with templates, functionality, devices, and content complexity. Repeated detail pages and unique business pages require very different effort.
Is approval through WeChat or another messaging tool valid?
Email, project-management tools, and message history can all help evidence communication in practice. Define which channels count as formal approval and preserve downloadable, traceable records at critical milestones.
Why is “revise until satisfied” risky?
“Satisfied” has no objective boundary. Define the number of directions, revision rounds, and feedback process, and distinguish refinement, a new direction, and added scope.
Can a kickoff payment be called earnest money?
The legal consequences differ. Whether a substantial kickoff payment should use a legally defined term depends on the agreement and current law; qualified counsel should review it rather than relying on conversational habit.
Is a longer contract always safer?
No. What matters is whether clauses are executable, exhibits complete, and standards verifiable. Ten pages of vague language are less useful than three well-defined documents.
Related Service | Link |
|---|---|
Project inquiry | |
Website design and development | |
Brand identity design | |
UI/UX design |
