A website can become difficult to operate when the contract leaves ownership, access or maintenance unclear. Resolve those questions while the project is being scoped. The checklist below supports that conversation; the final contract must reflect the parties, applicable law and actual services.
Ownership and Access
1. What Rights Will You Receive?
Distinguish ownership of newly created work from licences for third-party code, fonts, images and services. State what rights transfer, how they may be used and when the transfer takes effect. Access to a repository and ownership of economic copyright are separate matters.
2. Who Controls the Domain?
Record the registrant, billing contact and authorised administrators. Make renewal and transfer responsibilities clear. Public registration records may not reveal every relevant detail, so verify control through the registrar account and contract.
3. Who Controls Hosting and Connected Services?
List hosting, DNS, CMS, analytics, email and payment accounts. Agree account ownership, access levels and what happens if the supplier relationship ends. A managed service can be appropriate when export and exit arrangements are clear.
4. What Is Handed Over, and When?
Specify repository access, build instructions, environment configuration, documentation and training. Record which items are provided at each milestone and which depend on final payment. Do not treat a ZIP file as proof that another team can operate the system.
Scope and Acceptance
5. What Is Included?
List page types, languages, content responsibilities, integrations and exclusions. Name the person authorised to approve changes. An example design is not a complete functional specification.
6. How Is the Schedule Agreed?
Document milestones, client inputs and feedback dependencies. Explain how approved changes or delayed inputs affect dates. A schedule is useful only when the responsibilities behind it are understood.
7. How Are Changes Managed?
Distinguish corrections against the agreed scope from additions to that scope. Specify the review process, included rounds and how price or timing changes are approved before work proceeds.
8. How Is the Work Accepted?
Use concrete tasks and test conditions: forms, transactions, editing, mobile layouts, accessibility and performance. Record defects and decisions in an acceptance document. Avoid relying on an unspecified lab score as the sole definition of quality.
Operation and Risk
9. What Does Maintenance Include?
Separate defect correction, dependency updates, monitoring, content changes and new features. State the included period, exclusions and arrangements after it ends.
10. What Response Commitments Apply?
Agree support hours, incident severity, response targets and escalation contacts. Response and resolution are different commitments. Contractual remedies should be negotiated for the actual project; there is no universal penalty or response time supplied by this checklist.
11. Can the Site Be Recovered and Moved?
Specify backups, restoration testing, access revocation and export arrangements. Assign responsibility for keeping account information and documentation current.
12. Who Is Responsible for Personal Data?
Map the data collected by forms, analytics and integrations. Determine controller and processor roles from the actual processing. Where a party processes personal data on another’s behalf, assess the necessary processing agreement and safeguards. A contact form alone does not establish every supplier’s legal role.
Q-Dev’s Delivery Terms
Q-Dev is QA10’s software house. We agree scope, price and schedule for each project. The four gates are design, MVP, deployment, and training with the start of maintenance. Each gate ends with a meeting and an agreed corrections document; after approval, two further rounds of changes to completed work are available at that gate. Changes can affect the schedule; price changes only when work falls outside the contract. The first six months of maintenance are included. Code rights transfer after payment for the entire project.