Why You Should Use a Web Design Contract (Plus What to Include In It)

Let’s face it, you never really know how a web design project is going to go. In some cases, it’s smooth sailing. You get everything done on time and with little pushback from the client. In other cases, not so much. 

A web design contract can help keep things on track. The trick is to create it with yours and your client’s best interests in mind. 

A web design contract is a document that defines the scope of the work to be done, the relationship between the parties involved, as well as the terms of the agreement. When signed, it is a legally enforceable contract. 

You might be wondering why you need to bother with using a contract. If you’re wondering that, then you might not have encountered the kinds of hiccups that contracts can protect you from. For instance: 

• A client that tries to change the scope of the project midway through
• A client that goes MIA for months
• A client that decides they hate everything you’ve designed after the site goes live and refuses to pay

I’m using examples of bad clients here to explain the value in having a contract, but that’s not the only reason to have one. A well-written contract provides protections and clear terms for both parties involved. 

If you do it right, a web design contract will help with the following:

• Ensure that everyone is on the same page. 
• Define your relationship as a freelancer or agency.
• Clearly detail the scope of work and deliverables owed.
• Define the payment terms and the penalties for violating them.
• Provide guidelines on how to deal with change of scope.
• Limit the number of revisions to keep the project moving along.
• Describe the client’s responsibilities and when they’re due to keep them accountable. 
• Determine the rules for disagreements and/or the termination of said agreement.

I believe the contract has two other important benefits. 

First is that, when you’re new, a web design contract can give your business a more polished look. This can help instill trust in clients who might be nervous about working with a new designer.

Second is that the contract can help you weed out the wrong-fit clients. Anyone who disputes the terms or refuses to sign it is someone you’ll have even more problems with down the road. So the contract can help save you from that.

You don’t need to write a web design contract yourself. While there are tons of web design templates you’ll find online, I’d recommend you try professional proposal and contract software like Bonsai or PandaDoc. They come with robust contracts written specifically for web designers and they make securing signatures easy. 

Regardless of which option you go with, every web design contract should cover the following items:

If you’ve ever worked on a project where everyone and their mother wants to weigh in on the client’s side, you know how difficult things can get. The person you thought was in charge said everything looked good, only to find out a few days later that the sales manager didn’t like your color choice. So even though you proceeded with the work based on the initial approval, you’re now having to backtrack. 

To keep this from happening, the contract must designate a single decision-maker on the client’s side. This will force your client and their team to collaborate internally before bringing any feedback or approvals to you. It will also clarify who they contact on your end so you and your team aren’t being inundated with questions, feedback, and results throughout the job.

If you want, you can place a Summary section at the top of the contract that explains the basics of the job. However, you should also have a Scope of Work section that spells everything out in nitty gritty details. For example:

• What you’re designing (e.g. website, ecommerce, mobile app, SaaS, logo)
• Number of pages
• Number of products
• Themes and plugins to be used
• Number of stock images
• Features to be added
• Custom functionality 
• Number of mockups for review
• Number of revision rounds
• SEO and what types

This should all be hashed out with the prospect during your initial discovery call and in the proposal stage. Once you have the finalized details, they go here in the contract. 

If the client decides at any point that they want to deviate from the scope (even if it’s to ask you to add 40 product pages instead of the 30 initially agreed upon), you should have a plan to deal with it. This subsection will explain what happens. 

For instance:

• Will the project be put on hold until the client submits an official request to change the scope?
• Will you update the contract and resubmit it for approval to the client?
• Will additional charges be added to the project total? How will this be determined?

This subsection ensures that the client is aware that they can alter the scope. However, if they do, there will be an adjustment to the contract, costs, and timeline if they do. 

I rarely see this section included in web design contract templates. However, it’s something that needs to be addressed. 

What you include here depends on what the client is responsible for. 

For example, if they owe you anything during the onboarding process, then you should list it out in the contract. This list could include things like:

• Logos
• Copy
• Imagery
• Themes or plugins
• Logins
• Onboarding questionnaire

Get specific with each. If you need a white and color version of the logo delivered as SVGs with transparent backgrounds, then spell it out. 

Also add a note about when each item is due. If that deadline is missed, explain what happens. For example, will you pause work until the client provides the required deliverables? What about if they can’t provide the deliverables? 

One of the issues I ran into often was a client promising to provide their own copy, but then not telling us until it was due that they couldn’t find anyone to write it. So we ended up having to put design and development on hold, contact one of our freelancers, and wait for them to write it. Then we had to put it through the proofreading process and hand it over to the client for their own review. 

If you can anticipate and address these types of issues in your contract, you’ll make it less likely that your client will commit these faux pas in the first place.

This section doesn’t need to be long. In it, you’ll lay out the projected timeline for the project. In addition to defining a start and end date, you should also chart out milestones. 

These are checkpoints where you have something to review with the client. As you gain their feedback and approval on what you’ve done, they’ll need to sign off on it and submit a milestone payment. 

Provide actual dates for the full timeline. Also describe what the client can expect to receive by that milestone, how many revisions are offered, and when feedback, approval, and payment is due by.

This will give you, your team, and your client something concrete to work off of. Just be sure to add a note that any changes to the scope or any delays in providing feedback or approvals could lead to a restructuring of the timeline. 

This section covers the payment details. Depending on the size of the project you’re working on, this section might only include the project total.

For larger and lengthier projects, it’s a good idea to stagger the payments out through the timeline. For example, it might look like this:

• 25% upfront deposit
• 25% at Milestone 1
• 25% at Milestone 2
• 25% prior to launch

In addition to explaining the payment schedule, you can include other fees in this section. You might add a kill fee for early termination, a late fee for late payments, or a fee for whenever the scope changes. 

At some point in the process, you’ll need to get feedback from the client. You’ve already laid out when they can expect these feedback and revision rounds to take place. You’ve also told them how many rounds of revisions there will be. 

In this section, you’ll address the feedback and approval process. 

As you send deliverables to the client over the course of the project, you don’t want to get stuck waiting around for their approval. But you also don’t want to proceed without it. 

That’s why it’s important to reiterate how many revisions there are along with what the feedback and approval windows are. Then explain what happens if they’re missed. 

For instance, let’s say you send website mockups to the client on Monday. The approval window is five business days. However, you haven’t heard from them by the following Monday. 

You could either put the job on hold until they return with feedback or you could proceed if the contract stipulates that no response means that the work is accepted by default. You’ll need to decide the terms in this section.

By the end of the project, you’ll have a stack of assets and information to hand over to the client. Your list could include things like: 

• Logo designs
• Market research report
• A style guide or design system
• Website design files
• Stock imagery
• Theme and plugin licenses

In addition, you’ll need to provide the client with logins to everything you set up on their behalf. This applies to web hosting, payment processors, as well as the website itself. 

In this section, you’ll write out everything you owe to the client, whether you deliver it in the middle of the job or the very end. 

You should also spell out the terms for handing over these deliverables during the offboarding process. For example, many designers require clients to approve the website (or whatever they built for them) and to make their final payment prior to handoff.

Most contract templates will provide this section pre-written for you. It’s just your standard verbiage explaining that you won’t disclose any of your client’s secrets. 

Even if it doesn’t seem necessary, keep this section in there for your client’s sake. It’ll give them some peace of mind when sharing information with you about their company and their competition.

This section mainly has to do with copyright infringement. Both you and your client will benefit from including this clause in the contract.

Your template should provide you with the proper wording for it, but the gist of it is this:

You both agree to use content that you have ownership of (or a license for) and the legal right to use. If either of you violate this agreement, the other party cannot be held accountable for copyright infringement and any legal action taken as a result. 

The main areas to emphasize are the copy and imagery. 

You want to ensure that any copy written for the website is 100% original. You may even want to include a clause that requires you and your team to run all copy through a plagiarism checker prior to launching the site.

As for the imagery, explain how critical it is to use images that you have taken yourself, own the license to, or got via Creative Commons. Anything pulled off of Google or another website cannot be used.

This section deals with the ownership of your creation. In the vast majority of cases, this will be a work-for-hire arrangement. So when the work is done and the client has approved and paid, they will take ownership of what you created.

Your contract template will have a small section that explains this. However, you may want to get extra clear about when ownership is transferred. This way, the client understands that they need to provide final, signed approval on the website and remit their final payment before it can go live and ownership given to them.

Another point you might want to address is credit. For instance, you might want to add a “Designed by” credit to the footer with a link to your site. You may also want to use this work in your public-facing portfolio. In that case, you should get the client’s permission to do so first.

Disputes arise. It sucks, but it’s one of those occupational hazards that web designers and agencies have to accept. 

If you are unable to handle the dispute amongst yourselves, then one of you might initiate legal action to get it resolved. This section of the contract will name the jurisdiction where the case will be heard or the state in which you can take them to small claims court. 

If you’re drawing up the contract, then set it to your state of residence.

There are times where you or the client may decide to terminate the contract altogether. The most common reason for termination is breach of contract — e.g. the client refuses to pay or the designer is unable to complete the work. 

However, you might need to terminate for other reasons. For example, the client could end up being so difficult to work with that nothing can get done and you’re sure that you’ll end up with a loss by the end of the job. 

In this section, lay out what happens when either party decides to terminate. 

For starters, how much notice needs to be given in order to terminate? 7 days? 30 days? 

Also, how will you resolve payment for completed work, even if you haven’t reached a milestone? Will you work until the next milestone is reached? Or will you issue an invoice for the total number of hours worked? And what rate will you charge?

It’s a good idea to hash this out now rather than wait to dispute it when tempers are flaring from an incomplete project.

This kind of warranty is similar to the warranty you’d get when buying electronics, furniture, or other expensive items. So what you’d do with this section is let clients know the timeframe in which their website is covered as well as what kind of damage would be covered.

For example, let’s say you add a six-month warranty. If something malfunctions during that time period, you would offer to fix it free of charge. 

But be careful about how you word this section. You don’t want to make it seem like you’ll fix anything for free — like a website that the client broke by poking around on the backend or a website that was hacked due to them disconnecting the SSL certificate.

On the other hand, you could fix things like the white screen of death appearing after a WordPress update. Or a plugin that’s no longer working as it had when you first installed it.

You can also add your fee for updates and support outside of the warranty. That way, the client won’t feel like they’re walking on eggshells every time they edit their site. Knowing you’ll be there to help them either way will be reassuring.

The last component of the web design contract is the signature line. Add the name of the decision-maker for both parties. Then leave room for signatures as well as dates. This is what makes the contract binding.

The contract is an important part of the web design process. If you kick things off without one, you might find it difficult to keep things on track or the client in line over the course of the job. 

Just keep in mind that the web design contract on its own is nothing more than a document. In order for it to be effective, you have to be willing to enforce the terms of it. This can be difficult to do if you’ve never had to say “no” to a client or to put a project on hold until getting paid. 

That’s just part of doing business with clients. If they’re not able to stick to the terms of the agreement (or can’t remember them), then you need to be able to do so. 

Having this contract in place, going over it with your client, and providing each other with a signed copy will help cut down on those disagreements. It will also help you iron out many of the ones that do arise later on.