Website Project Agreement: Scope and Timeline

A website project agreement should convert a sales conversation into a delivery system. It identifies the parties, defines the exact work, assigns responsibilities, explains approvals and changes, and states what happens when content, access, payment, or third-party services delay the schedule.

The template below is an educational scope framework. It is not a substitute for legal advice or a jurisdiction-specific contract. Ask a qualified professional to review the final agreement, especially intellectual property, liability, privacy, tax, dispute, and termination clauses.

Quick Answer

At minimum, document:

• parties and authorised contacts;
• project objective;
• pages, templates, features, and content;
• exclusions;
• client and developer responsibilities;
• milestones and dependencies;
• review and revision process;
• fees and third-party costs;
• acceptance criteria;
• launch and handover;
• intellectual property and licences;
• confidentiality and data access;
• support, change, pause, and termination rules.

An agreement should be specific enough that a new team member can determine whether a request is included without relying on memory.

1. Parties and Authority

Record the legal or business names, addresses, contact details, and authorised approvers. Clarify:

• who can approve scope and design;
• who can approve additional cost;
• who supplies content and credentials;
• where formal notices are sent;
• whether an employee or agency is acting for another entity.

Feedback from several stakeholders should be consolidated by one authorised contact. This prevents one approver accepting a design while another later resets the direction.

2. Project Objective

Write one measurable business objective before listing pages.

Examples:

• generate qualified enquiries for three services;
• publish an editable product catalogue with quote requests;
• replace an outdated site while preserving approved URLs;
• launch a booking flow with staff scheduling;
• create a customer portal for document access.

Avoid objectives such as “modern premium website” unless the agreement defines how that is reviewed.

3. Deliverable Register

Use a table instead of one paragraph.

For each row, specify quantity and variations. “Service pages” should say whether there are 3 or 30, one reusable template or unique layouts, and who supplies the copy.

4. Exclusions

Exclusions are not negative; they prevent incorrect assumptions.

Common exclusions may include:

• logo or full brand identity;
• photography/video;
• translation;
• legal policy drafting;
• unlimited content entry;
• paid advertising;
• guaranteed search rankings;
• premium licences;
• payment gateway or WhatsApp provider fees;
• CRM data cleanup;
• custom portal modules;
• ongoing maintenance after the support period.

If an excluded item is likely later, state that it can be quoted through change control.

5. Content Responsibility

Define a content register:

• page or record;
• required copy;
• image/document;
• owner;
• due date;
• format;
• approval status.

If the developer provides copywriting, define interview inputs, word range, revision rounds, SEO research boundary, and who verifies factual or regulated claims. If the client provides content, state how late delivery affects the schedule.

6. Technical Scope

Record:

• framework or CMS where relevant;
• hosting responsibility;
• supported browsers/devices;
• responsive expectations;
• integrations and provider accounts;
• data migration quantity and format;
• forms and notification destinations;
• accessibility target if agreed;
• performance test method if agreed;
• security and backup responsibilities;
• environments such as staging and production.

Do not promise an exact performance score without defining device, network, test tool, page, third-party scripts, and content state.

7. Timeline and Dependencies

A date alone is not a schedule. Use milestones with dependencies.

Define working days, holidays, feedback window, and the effect of delayed input. A timeline should move when a required dependency moves.

8. Revisions

State:

• number of revision rounds;
• which deliverable each round covers;
• feedback format;
• who consolidates comments;
• difference between revision and new scope;
• treatment of requests after approval.

A revision adjusts an approved deliverable within the original objective. A new user role, page type, integration, workflow, or content batch is usually a change request.

9. Change Control

Use a simple written form:

Change request:
Reason:
Affected deliverables:
Additional fee:
Schedule impact:
Acceptance test:
Approved by:
Approval date:

No changed work should rely on “we discussed this on a call” when it affects cost, architecture, or timeline.

10. Fees and Payment Schedule

List:

• total professional fee;
• taxes where applicable;
• advance;
• milestone amount and trigger;
• payment due period;
• late or pause treatment;
• third-party cost;
• refund/cancellation handling;
• currency and payment method.

Connect milestone payment to evidence, not an estimated percentage complete. See safe payment terms for website projects for a detailed milestone method.

11. Acceptance

Acceptance criteria can include:

• named pages exist;
• approved text/images are populated;
• mobile layouts pass agreed viewport checks;
• forms deliver to the named destination;
• required events fire;
• links and navigation work;
• metadata/canonical/sitemap meet scope;
• agreed integrations pass test cases;
• no unresolved severity-one defects;
• client receives account access.

Define the defect reporting window and what happens if the client does not respond.

12. Intellectual Property and Licences

Ask professional counsel to define:

• when ownership transfers;
• whether transfer depends on full payment;
• treatment of pre-existing developer tools;
• open-source licences;
• premium themes/plugins/fonts/media;
• stock asset restrictions;
• reusable generic components;
• rejected concepts;
• portfolio/display permission;
• client trademarks and supplied content.

“Client owns the website” can mean domain, content, source, database, design, or deployment account. Name each asset.

13. Accounts, Credentials, and Data

Business-critical accounts should have an owner register:

• domain registrar;
• DNS;
• hosting;
• email;
• CMS;
• repository;
• analytics;
• Search Console;
• payment/WhatsApp/API providers;
• backups.

Use individual access and least privilege. Do not put passwords or API secrets inside the agreement. Define secure transfer and revocation.

14. Confidentiality and Privacy

Record whether the developer may access customer, employee, payment, medical, education, or other sensitive data. Define:

• permitted purpose;
• minimum access;
• test data;
• approved subcontractors;
• breach/incident communication;
• return or deletion at project end;
• client responsibility for lawful collection and policy content.

This section requires professional review when personal or regulated information is involved.

15. Launch, Handover, and Support

Define:

• launch window;
• DNS responsibility;
• rollback plan;
• production smoke test;
• training;
• documentation;
• source/export delivery;
• defect warranty;
• support channels/hours;
• response versus resolution expectations;
• maintenance options after support.

Separate defect correction, operating support, maintenance, and enhancements.

16. Pause and Termination

Professional review is important here. Operational questions include:

• what counts as a material delay;
• when either party may pause;
• notice period;
• fees for completed work;
• handling of advance and third-party costs;
• delivery of paid work;
• deletion/return of access and data;
• confidentiality after termination;
• restart conditions.

Current VASUYASHII Scope Practice

VASUYASHII uses project requirements and phased deliverables to distinguish marketing websites from custom software, integrations, and future modules. The free software project requirement template can provide the source material for an agreement, but it is not itself a legal contract.

Published VASUYASHII product pages also separate current features from roadmap items. Agreements should follow the same evidence rule: only approved present scope belongs in the base fee.

Agreement Review Checklist

• [ ] parties and approvers are identified;
• [ ] objective is specific;
• [ ] pages/templates/features have quantities;
• [ ] content ownership and dates are written;
• [ ] exclusions are visible;
• [ ] integrations name accounts and test cases;
• [ ] timeline shows dependencies;
• [ ] revisions and change requests are separate;
• [ ] milestone acceptance is measurable;
• [ ] account and IP ownership are explicit;
• [ ] privacy/data access is addressed;
• [ ] launch and rollback are defined;
• [ ] handover assets are listed;
• [ ] support and maintenance are separate;
• [ ] pause/termination has professional review.

Common Mistakes

Copying a Generic Contract Without the Real Scope

Legal language cannot replace a page, feature, content, and acceptance register.

Using “SEO Included”

Name metadata, technical checks, content, tracking, reporting, and exclusions.

Treating Unlimited Revisions as Collaboration

Unlimited feedback removes schedule and acceptance boundaries.

Ignoring Client Dependencies

A launch date cannot remain fixed when required content or provider access is late.

Leaving Ownership Until Final Payment

Define transfer, licences, accounts, and handover at the start.

FAQs

Is this article a legal agreement?

No. It is a project-scope framework. Have the final legal document reviewed by a qualified professional.

Should the agreement list every page?

Yes, or reference an attached approved page register with quantities and template rules.

What belongs in exclusions?

Anything a reasonable buyer might assume but that is not priced, such as copywriting, photography, premium licences, migration, advanced SEO, or maintenance.

Can the timeline change?

It should explain how approved change requests, delayed dependencies, provider issues, or force-majeure events affect dates.

Who should own the domain and hosting?

The business should normally control critical accounts, with appropriate access granted to the delivery team.

Is email approval enough?

The legal effect varies. Operationally, use a named approval channel and preserve clear records; ask counsel what the agreement requires.

Related Reading

• Safe payment terms for website projects
• Website delivery checklist
• Professional website package inclusions
• How to check if a developer is genuine
• Maintenance plan checklist
• Software requirement template

Conclusion

A strong agreement is an operating map: what will be delivered, what will not, who must act, how progress is accepted, and how the relationship closes safely.

Prepare the requirement register first, obtain professional legal review, and keep every change traceable. For a scoped website or software delivery plan, contact VASUYASHII.