Website Design Service Agreement: Revisions and Design Ownership (Service-Provider Guide)

As a web designer or design agency, you’ve probably lived this scenario: you deliver a polished homepage concept, the client loves it—then asks for “just a few tweaks.” Those tweaks turn into multiple rounds of changes, a brand-new layout direction, and a moving target for approval. Meanwhile, your timeline slips, your team’s margin evaporates, and the project quietly becomes unprofitable.

A well-structured web design service agreement is how you prevent that outcome. More specifically, the two clauses that most often determine whether a project stays healthy (or becomes a scope vortex) are:

1. Revisions (what’s included, how many rounds, what counts as a revision, and what happens when revision limits are exceeded)
2. Design ownership (what the client owns, what you keep, when ownership transfers, and how licensing works)

This guide breaks down how to handle both, from the perspective of the service provider, with practical drafting tips you can adapt into a website design contract template, a web designer agreement, or a website design contract with revisions that fits your process.

---

Why revisions and design ownership matter more than you think

Revisions protect your time, timeline, and profitability

Without clear revision terms, clients may assume unlimited changes are included. That assumption creates:

• Undefined scope (“can we also redesign the pricing page?”)
• Uncontrolled iterations (“let’s explore three new directions”)
• Approval bottlenecks (no feedback for two weeks, then urgent changes)

A revisions clause is not “being difficult”—it’s a project-management tool that sets expectations and creates a fair path for changes.

Ownership clauses prevent disputes about files, reuse, and payment leverage

Design ownership is frequently misunderstood. Clients may assume they automatically own:

• All design concepts (even unused drafts)
• Source files (Figma, PSD, Sketch)
• Your internal component libraries, templates, or code snippets
• Stock assets you licensed under your account

If your web designer agreement doesn’t address these issues, you can end up handing over more than you intended—or facing conflict when you reuse a pattern you built for them on a future project.

---

Revisions in a website design contract: what to include

A “revisions” clause should do more than state a number. It should define process.

1) Define what counts as a “revision” vs. new scope

Most conflict comes from different interpretations of “revision.” Your contract should clarify that revisions are:

• Adjustments to previously delivered work within the approved direction
• Based on consolidated feedback provided within a defined timeframe
• Limited to the deliverables listed in the scope (e.g., homepage + about + contact)

Then explicitly state what is not a revision and becomes a change request, such as:

• Switching to a new design direction after approval
• Adding new pages or new features
• Replacing approved content with new content that affects layout (e.g., longer copy, new sections)
• Structural changes (e.g., new navigation architecture) after wireframes are approved
• New integrations, new components, or new device breakpoints not in scope

Service-provider tip: Add language requiring the client to provide feedback in a single, consolidated list per round. This reduces “one-off” emails that restart the clock.

2) Set revision rounds (and keep them realistic)

For many agencies, a reasonable baseline is:

• 1–2 rounds on wireframes (if included)
• 2 rounds on visual design (UI comps)
• 1–2 rounds on development QA (bug fixes vs. subjective design changes)

You can phrase this as “rounds” or as a fixed number of hours. Rounds are simpler for clients to understand; hours can be more precise.

Example structure:

• “Up to two (2) rounds of revisions per page design deliverable.”
• “Each revision round must be requested within five (5) business days of delivery.”

3) Put guardrails around timelines (feedback windows + approval)

Revision limits only work if you also manage response time.

Include:

• A feedback deadline (e.g., 5 business days)
• An approval mechanism (written approval via email, project tool, or signature)
• A deemed approval option (if client is unresponsive)

Why it matters: if the client delays feedback, you may lose your production slot, incur rework costs, or have to re-onboard the project.

4) Explain what happens when revision limits are exceeded

This is the clause that turns revision limits into reality.

Your website design contract with revisions should state that additional revisions are billed:

• At an hourly rate, or
• As a fixed “additional revision round” fee, or
• Via a formal change order

Add clarity on timing too:

• Additional revisions may extend deadlines.
• Work does not start on out-of-scope changes until written approval and payment terms are confirmed.

5) Separate “bug fixes” from “design changes”

Once development begins, “revisions” can blur into QA. Avoid disputes by distinguishing:

• Bug fixes: something not functioning as specified (included)
• Design changes: preference-based modifications (billable if beyond included rounds)

Example: “Button hover state not working on Safari” is a bug. “Make the buttons slightly rounder and change the animation style” is a design change.

6) Require the right tools and inputs

If you want feedback inside Figma comments, or you require brand assets before design starts, put it in the agreement.

Common input requirements:

• Brand guidelines (logos, fonts, colors)
• Copy and images by a specific date
• Access credentials (hosting/CMS) for implementation
• Third-party accounts (analytics, email marketing, payment processors)

If delays occur because inputs aren’t delivered, your contract should permit timeline adjustments.

---

Design ownership: who owns what, and when?

Design ownership isn’t one question—it’s several. A strong web design service agreement separates them clearly:

1. Ownership of the final deliverables
2. Rights to preliminary concepts and rejected drafts
3. Ownership of tools, templates, and pre-existing IP
4. Licensing of third-party assets
5. Transfer timing and conditions (often tied to payment)

1) Clarify “deliverables” vs. “working files”

Clients often want “everything.” You should be explicit about what “everything” includes.

• Deliverables: the final exported assets agreed in scope (e.g., approved page designs, style guide, icons created specifically for the client, final website build).
• Working/source files: Figma files with components, internal notes, plugins, unused concepts, or layered source files.

Many agencies deliver final outputs but retain ownership of working files unless the client pays for them. If you want that option, state it clearly.

Service-provider positioning:

• Offer source files as an add-on with a defined fee.
• Or license them for internal use only (no resale).

2) Tie ownership transfer to full payment

This is one of the most important protections you can add to a website design contract template.

Common approach:

• You grant a limited license for review during the project.
• Full ownership (or broad usage rights) transfers only upon final payment.

Why it matters: it prevents a client from using the work while disputing invoices, and it gives you leverage without threatening relationships.

3) Decide whether you assign copyright or license the work

There are two common models:

A) Assignment (client owns the final design)

• Client receives full ownership in the final deliverables after payment.
• You retain rights to pre-existing materials and general know-how.
• You may reserve portfolio rights.

B) License (you retain ownership; client gets broad usage rights)

• Often used for subscription design services, template-based builds, or when the provider wants to reuse systems.
• Client receives a perpetual, non-exclusive (or exclusive) license for their business.

Either can be fine—what matters is that your agreement matches your business model.

4) Keep your pre-existing IP and reusable components

Most designers use frameworks, starter themes, component libraries, and internal processes developed over time. Your contract should state that:

• Pre-existing tools and templates remain yours.
• You grant the client a license to use them only as embedded in the final deliverables, or only for their site.

This protects you from a client claiming ownership over your system because it appeared in their project.

5) Address third-party assets (fonts, photos, plugins)

Design ownership is limited by licenses. If you use stock photography, premium fonts, or paid plugins:

• Identify who is responsible for purchasing licenses.
• Specify whether the client’s use is covered under your license (often it isn’t).
• Clarify that the client must maintain subscriptions for ongoing use/updates (especially for plugins).

A clean way to frame it:

• “Third-party materials are subject to their respective licenses and are not transferred beyond the rights granted by those licenses.”

6) Portfolio and marketing rights

Most designers want the right to show completed work. Include:

• Permission to display the project in your portfolio, website, awards, and social media
• Any confidentiality or embargo period (common for product launches)
• Whether you can display the client’s name/logo

If a client is sensitive, offer an opt-out—or a delayed showcase.

---

Best-practice clause structure (plain-English drafting tips)

You don’t need to write like a law textbook for your web designer agreement to be enforceable. In fact, clarity reduces disputes.

Consider organizing your contract like this:

1. Scope of work (deliverables + what’s excluded)
2. Design process & approvals (milestones, sign-off points)
3. Revisions (rounds, feedback method, deadlines, overage fees)
4. Change requests (what triggers a change order, pricing, timeline impact)
5. Fees & payment (deposit, milestones, late fees)
6. Ownership & licensing (deliverables, working files, pre-existing IP, transfer timing)
7. Third-party materials (client responsibilities)
8. Portfolio rights & confidentiality
9. Termination (kill fee, work completed to date, license status)
10. Limitation of liability (especially for indirect damages)

---

Common pitfalls agencies should avoid (and how to fix them)

Pitfall 1: “Unlimited revisions” in sales proposals

If you want to offer a premium experience, “unlimited revisions” can be positioned—but it’s risky in a fixed-fee project.

Fix:

• Offer “reasonable revisions” only when paired with hourly billing or a time-boxed subscription model.
• Or define “unlimited” as unlimited within a set number of hours per month.

Pitfall 2: No definition of revision rounds

Without a definition, clients may treat every email as a new revision round.

Fix:

• Define a revision round as a consolidated set of changes delivered at once.
• Require changes to be submitted via a single channel (e.g., Figma comments).

Pitfall 3: Handing over source files by default

If your internal system is valuable, giving away working files can undercut your competitive advantage.

Fix:

• Deliver exports by default; sell source files as an add-on.
• If you deliver source files, restrict reuse/resale.

Pitfall 4: Ownership transfers before final payment

This can lead to payment disputes where the client already has everything they need.

Fix:

• Explicitly tie ownership assignment/license expansion to full payment.

Pitfall 5: Ignoring third-party licenses

Clients assume “you handled it,” then they get a licensing notice later.

Fix:

• Spell out who purchases and maintains licenses.
• Provide a list of third-party assets used (or require client-provided assets).

---

Sample language ideas (for inspiration, not legal advice)

Below are drafting concepts you can adapt into your website design contract template. Always have counsel review for your jurisdiction and business model.

Revisions (conceptual sample)

• “Fee includes up to two (2) revision rounds per deliverable. A ‘revision round’ means one consolidated set of changes submitted by Client within five (5) business days of delivery.”
• “Requests that materially alter approved direction, add new features/pages, or require rework of previously approved deliverables constitute a Change Request and may require a change order.”
• “Additional revisions are billed at $___/hour and may extend delivery dates.”

Ownership transfer (conceptual sample)

• “Upon receipt of full payment, Designer assigns to Client all right, title, and interest in the final deliverables created specifically for Client under this Agreement, excluding Designer’s pre-existing materials, tools, templates, and general know-how.”
• “Working files (including source files and unused concepts) are not included unless expressly listed as deliverables.”

Pre-existing IP (conceptual sample)

• “Designer retains all rights to pre-existing materials, frameworks, templates, and processes. To the extent such materials are incorporated into deliverables, Designer grants Client a license to use them solely as part of the deliverables for Client’s internal business purposes.”

---

How to position revision limits without losing deals

Clients rarely object to revision limits when you explain them as a quality-control system.

Try framing like:

• “Revision rounds keep feedback organized and prevent missed details.”
• “We include two rounds because that’s typically enough to refine the direction while keeping the timeline on track.”
• “If you want more exploration, we can absolutely do that—we’ll just handle it as additional design time so it’s fair to both sides.”

This turns a hard “no” into a transparent process.

---

Bringing it all together in a web design service agreement

A professional web design service agreement makes your project predictable:

• The client knows what they’re getting and how to request changes.
• You know when you’re done, what you’re delivering, and what you retain.
• Both sides understand how ownership works, especially if payment issues arise.

If you’re building or updating a website design contract with revisions, treat revisions and ownership as foundational—not optional fine print.

In many cases, tightening these two areas is the fastest way to reduce difficult projects, protect margins, and improve client satisfaction (yes, really—because clear boundaries reduce confusion).

To streamline the drafting process, you can generate a contract that includes revision limits, change-order mechanics, and design ownership language tailored to your workflow using Contractable, an AI-powered contract generator: https://www.contractable.ai

---

Other questions to continue learning

• How do I choose between fixed-fee pricing and hourly billing in a web designer agreement?
• What’s the best way to write a change order clause for web design projects?
• Should I include a “deemed approval” clause, and how do I enforce it?
• Can I reuse UI components or layouts from a client project in future work?
• What deliverables should be listed in a website design contract template for Figma-based workflows?
• How should agencies handle client-provided content delays in the timeline clause?
• What’s a fair kill fee/termination provision for a web design service agreement?
• Do I need a separate NDA, or should confidentiality be built into the contract?
• How do I handle accessibility (WCAG) responsibilities in a website design contract?
• What ownership terms should apply to custom code vs. design files vs. CMS configuration?