What should a website contract include?

Why does a website contract matter before a single pixel is drawn?

A contract is not a sign of distrust. It is a shared record of what both sides agreed to, written down while everyone is still friendly and aligned. Once a project is underway and expectations diverge, a clear written agreement is the only thing that resolves the disagreement without lawyers, lost money, or a half-finished website sitting on a staging server going nowhere.

The most common web design disputes are not about talent or effort. They are about things no one wrote down: how many pages were included, who owns the files when the project ends, what counts as a revision, and who is responsible when a deadline slips. A well-written contract makes all of those questions answerable before they become arguments.

If a designer or studio is reluctant to put the agreement in writing, that reluctance is itself informative. Any professional should expect a contract and be comfortable with one.

What should the scope of work section say?

The scope of work is the most important clause in the entire document because it defines the boundaries of the project. Everything from pricing to revision limits to deadlines flows from it. A vague scope is the single most common cause of web design disputes.

A good scope of work section names:

• The exact number of pages, listed by name, not by a round estimate like "about five pages."
• The functionality included, such as a contact form, a booking widget, an image gallery, or an e-commerce checkout. Each feature should be explicitly listed. If it is not in the list, it is not in the project.
• What is excluded. This is as important as what is included. If copywriting, photography, logo design, or third-party software are the client's responsibility, say so plainly.
• The platform or technology the site will be built on, so there is no ambiguity later about whether you own a portable codebase or a locked-in template.
• Deliverables at each stage, for example a design mockup for approval before coding begins, and then a staging link for review before launch.

When you are comparing what different studios are offering before you sign anything, the scope section of the contract is where you see whether two quotes are actually for the same thing. Our website cost comparison guide walks through how scope differences create price differences that are easy to miss.

What payment terms should a website contract spell out?

Payment terms tell you when money changes hands, how much, and under what conditions. A professional contract is specific here, not vague about "payment on completion" with nothing else defined.

The standard structure for a web design project is a deposit at signing followed by one or more milestone payments, with a final balance due at launch or delivery. The contract should state:

• The deposit amount and when it is due. A deposit of 30 to 50 percent of the project total is typical for most studios. If you are wondering whether a deposit is normal and what protections you should expect around it, the guide on whether you should pay a deposit for a website covers that in detail.
• The milestone payment schedule, including what triggers each payment. "Payment due when design is approved" is clearer than "payment due mid-project."
• The final balance trigger. This is usually site launch or handover of files, whichever comes first.
• What currency and method are accepted. This avoids confusion on international projects or when payment processors charge fees.
• Late payment terms. If a client is slow to pay and the designer cannot continue work as a result, the contract should say what happens, for example work pauses until payment clears.
• The refund policy for the deposit. Under what conditions is the deposit refundable, and under what conditions is it not.

How should a contract handle intellectual property and ownership?

This is the clause that most clients skip reading and most regret skipping later. In most jurisdictions, copyright in a creative work belongs to its creator unless there is a written agreement that transfers it. If your contract is silent on ownership, paying in full does not automatically mean you own the design, the code, or the assets.

A complete ownership clause should state:

• That full intellectual property rights transfer to the client upon final payment. This should cover the design files, the code, images produced for the project, and any other deliverables.
• What the designer retains the right to do. Most designers keep the right to show the work in their portfolio, which is standard and reasonable. That exception should be named explicitly so it is understood by both sides.
• Third-party assets and licenses. If the project uses stock photography, paid font licenses, or third-party plugins, the contract should clarify who owns those licenses and whether they transfer to the client or need to be purchased separately.
• What happens to files if the project is cancelled. If you pay 60 percent of a project and then cancel, do you receive the work completed so far? This should be answered in writing.

If the contract you are reviewing does not address ownership, or addresses it in language that is ambiguous, ask for clarification before signing. A vague phrase like "client receives the finished website" does not mean the same thing as "all intellectual property transfers to the client upon final payment." The difference matters if you ever want to move the site to a different host, hand it to another developer, or make changes without going back to the original studio.

What should the contract say about revisions and changes?

Revisions are where friendly projects quietly become expensive ones. Without a written limit, a client can request changes indefinitely and a designer can interpret "revision" to mean almost anything. The contract should define both the quantity and the scope of what is included.

Specifically, a revision clause should cover:

• How many revision rounds are included at each stage. For example, two rounds of design revisions before coding begins, and one round of content edits before launch.
• What constitutes a revision versus a scope change. Adjusting the color of a button is a revision. Adding a page that was not in the original scope is a change order, billed separately.
• The rate for additional revisions or change orders. This should be a clear hourly or per-item rate so there are no surprises when extra work is requested.
• The process for approving changes. Written approval, even by email, creates a paper trail. A good contract says that both parties must agree in writing before out-of-scope work begins.

FineWright includes two free edits on single-page builds and four on multi-page sites, stated clearly before any project begins. That number appears on the FineWright pricing page alongside every build price, so there is no ambiguity.

What should the contract say about the timeline and deadlines?

A timeline without consequences is just a wish list. The contract should define the schedule and attach meaning to it.

A solid timeline clause covers:

• The expected start date, usually tied to receipt of the deposit and any required client materials.
• Key milestones with dates, such as delivery of the first design direction, design approval, coding completion, and launch.
• Client response windows. If the designer delivers a design for review and the client takes three weeks to respond, the project timeline shifts. The contract should state how long the client has to review deliverables and what happens to the timeline if that window is missed.
• What constitutes a designer-caused delay and what remedies apply. If the studio misses a deadline through no fault of the client, the client should have a defined recourse, whether that is a revised timeline, a discount, or the right to terminate with a partial refund.

Realistic build timelines are also worth understanding before you sign. A custom single-page site can often be delivered in about one week with a competent studio. A multi-page custom site is typically a two-week build. If a quoted timeline is dramatically longer or shorter than those benchmarks with no explanation, ask why.

What should a website contract say about cancellation and kill fees?

Projects end early sometimes, on both sides. A client's business situation changes, or a designer takes on too much and cannot deliver. The contract should define what happens in both scenarios without anyone needing to guess.

A termination clause should address:

• The client's right to cancel. Under what conditions can you cancel the project, and what do you owe the designer for work already completed?
• The kill fee structure. A kill fee compensates the designer for time spent and capacity blocked. A fair kill fee is proportional to the work completed, for example 25 percent of the total if the project is cancelled after the design stage. The deposit often serves as the kill fee on smaller projects.
• The designer's right to terminate. If a client is consistently unresponsive, fails to provide required materials, or misses payments, the designer should be able to end the engagement without continuing to be bound by the original terms.
• What happens to deliverables on termination. Who keeps the design files? Is the client entitled to any work completed up to the cancellation point? This should be stated explicitly, not left to negotiation in the heat of a dispute.

What client responsibilities should the contract spell out?

A website project is not a one-way street. The designer needs things from you to do their job, and if those things arrive late or not at all, the project stalls. A professional contract assigns responsibilities to the client explicitly, so delays caused by missing content or slow approvals do not become the designer's problem.

Client obligations commonly named in web design contracts include:

• Providing all text content, images, logos, and brand assets by a specified date.
• Giving timely feedback within the agreed review windows at each stage.
• Providing access to existing accounts, such as the domain registrar or a previous hosting login, when needed.
• Designating a single point of contact so the designer is not receiving conflicting instructions from multiple people at the same company.

When content arrives late and the timeline slips as a result, the contract protects the designer from being blamed for a delay that was the client's fault. It also protects the client by making clear what they need to do and when, so there are no vague excuses about why the site is not finished.

What does a contract not protect you from?

A contract is a legal document, not a guarantee of quality or competence. It protects you from unclear agreements and bad-faith behavior, but it does not tell you whether a designer can actually do the work they are promising.

Before you get to the contract stage, the quality signals matter: live examples of past work, a clear explanation of the process, published pricing that does not shift depending on what you seem willing to pay, and a scope conversation that is specific rather than reassuring but vague. Choosing poorly and then enforcing a contract is still a bad outcome. The contract is the last line of defense, not the first.

It is also worth understanding the full cost picture before committing. Projects that look inexpensive upfront can carry ongoing costs, maintenance obligations, or platform lock-in that changes the real price over time. The guide on what a cheap website really costs you covers the hidden costs that a low quote does not show.

Frequently asked questions

Is a verbal agreement enough for a website project?

No. A verbal agreement is nearly impossible to enforce if a dispute arises over scope, ownership, or payment. A written contract protects both sides by creating a shared record of exactly what was agreed. Any professional designer or studio should expect to sign one.

Who owns the website if the contract does not mention ownership?

In most jurisdictions, copyright in a creative work belongs to the person who created it unless there is a written agreement transferring it. If your contract is silent on ownership, the designer may legally own the design, code, and assets even after you have paid in full. Always insist on an explicit intellectual property transfer clause.

What is a kill fee in a web design contract?

A kill fee is a sum you agree to pay if you cancel the project after work has started but before it is finished. It compensates the designer for work already done and time blocked out. A fair kill fee is tied to the percentage of work completed, not an arbitrary flat penalty. The deposit often functions as the kill fee in smaller projects.

Should the contract specify how many revisions are included?

Yes, and this is one of the most important practical clauses in a web design agreement. Without a revision limit, a project can stall indefinitely as requests accumulate. A good contract names the number of included revision rounds per stage and states a rate for additional rounds so both sides know where the boundary is.

What happens if the designer misses the deadline in the contract?

The contract should state what constitutes a timeline breach and what remedies apply, such as a price reduction, the right to terminate and receive a partial refund, or a revised completion date. Without this clause, a missed deadline has no contractual consequence and you have little leverage.

Does a website contract need to be reviewed by a lawyer?

For a straightforward small business website project you do not necessarily need a lawyer to review the contract, but you should read every clause yourself and ask the designer to explain anything unclear before you sign. For larger, more complex builds or when significant money is involved, a brief legal review is a reasonable investment.

Keep reading: should you pay a deposit for a website, what a cheap website really costs you, and how to compare website costs and make the right decision.