The Anatomy of a Good Web Development Contract

It’s not that uncommon for freelancer web developers to work for clients without official contracts or signed proposals. I know people who start $5,000 website projects after one discussion and a handshake. That may work in Mayberry, but in the real world, you’re setting yourself up for a heap o’ trouble if something goes wrong. It’s super dangerous to operate without the scope of the project, particulars of payment and other terms in writing. At the very least, you could have an unhappy client or an unprofitable project. At worst, you could have a nonpayment situation or even a lawsuit on your hands.

An email is better than a handshake, but a signed and dated contract is the way to go if you want to make sure everyone is on the same page about each of your projects.

Your contract with clients should include some basic legal jargon such as:

• Parties involved
• Scope of work / project details
• Payment terms
• Ownership rights
• Warranties
• Limitation of liabilities
• Independent contractor status
• Signatures and dates

Those things are all the legal gobbledygook of the contract and should be written or reviewed by a lawyer. Or if you can’t afford a lawyer, start with a web development contract template from a reputable online legal source like Legal Zoom or Rocket Lawyer or check out the Freelancers Union contract help.

Other parts of the web development contract aren’t necessarily legally required but are important to establish understanding, set client expectations and limit the scope creep of a project.

What to include in your web development contract

Executive Summary

This is a section (usually the first page of a proposal) that contains a short summary of what is included in the scope of the project, the price and payment details. If you are doing a very small project (say a website maintenance project), you may not need much beyond an executive summary. But the bigger the project, the longer your proposal will be. The purpose of the executive summary is so anyone can quickly look at the first page and understand what they are hiring you for and for what price without having to read a 10-page contract.

Objective

This is usually the beginning of the proposal where you say not only what you’re doing, but what is the point of this project? When you are doing the initial discovery interview to find out what your client needs, the most important question to ask that often gets overlooked, is “Why do you want to do this project?”

The answer to this question is the key to knowing how to sell the project back to them.

For example, if you ask a business owner why they want to redesign their website, and he says, “My website is so out of date I’m embarrassed to show it to clients.” In your proposal, you start off with something like this:

“In order to build trust and attract new clients, you need an updated website that is professional and modern. We will build you a website you can be proud to show your clients.”

The objective section should focus on the big picture outcomes of the project while you mirror your client’s language. You may literally use their words or sometimes using the opposite of their words. Describe their pain points and how you have the solution.

Outcomes

The more you can show your client a return on their investment (ROI), the more you can charge and the easier your projects will be to sell. If you are able to guarantee and demonstrate improvement for a client’s business (this could be sales, website conversions, increased brand awareness, more website visitors), this is the place to do it. But be careful with promising anything you can’t back up or guarantee. Over-promising could lead to a client unwilling to pay you for your work.

Timeline

The timeline could be as simple as a date that acts as a final deadline for project completion or a complex schedule of tasks and milestones set on a calendar to be completed over months. Especially for design-related things, you may want to agree to a deadline for the first demo or mockup of a project and leave it open ended when the final deliverables will be completed. You’ll learn you can’t control or predict when the client will get back to you or how many (or how extensive) the revisions will be. Sometimes they will email you within the hour and other times it will be weeks before you hear back from them. Don’t leave yourself on the hook for their communication delays. You could even include a timeline range and some disclaimers about that range (i.e. 2-3 months from the time we get the signed contract depending on the client’s responsiveness and the number of revisions…).

Communication

Proposals should include a section about what is “reasonable” communication turnaround for both parties. For example, if you ask for some kind of login information for the client’s website, they need to respond within three business days, or there will be delays in the project (and hence the deadline we agreed upon changes). These communication guidelines should work both ways. It’s a relief to the client if you are also promising to respond to their emails and calls within three business days. That reduces their perceived risk of having a freelancer who drops off the face of the planet.

Outline the form of communication that is preferred (i.e. email only or calls may be scheduled upon request or weekly touch-base meetings via Skype). Whatever way you want to set up the communication is up to you, just make sure it is clear in your contract.

Stakeholders

Listing the people who will be making decisions and signing off on the project milestones will be huge when the project drags on for months, the client gets a new guy on their marketing team, and he wants to change everything you’ve already completed. You can refer back to this section of the proposal if the project starts going off the rails because there are new people involved. And it goes without saying, the more decision makers the client has, the more you charge them. Group consensus can be difficult (if not impossible) with design and big web projects, so plan for plenty of back-and-forth discussion and revisions. You might want to add 5-10% onto the price tag for every stakeholder. This is also called the PITA Tax (aka the Pain In The Ass Tax).

Milestones or Benchmarks

Milestones are tasks that will be completed or outcomes that will be achieved by certain points during the project. Including these (and adhering to them) is essential project management. Imagine how badly a project could go if you talked to a client in June, spent a whole summer working on their website without talking to them and sent them a link when the site is live in September. Yikes. Milestones (or benchmarks) are check-in points to throw the client a bone to maintain momentum and demonstrate progress. They are opportunities to get feedback – and also progress payments – from the client.

Deliverables

The deliverables is a jargony way to say “what the client gets.” If you’re building a website, the deliverables will obviously include a website and all its bells and whistles. But it may also include training, instructions or technical support. This is your chance to get deep into the nitty gritty details. Include what tools and software you are using for the job, file formats of deliverables and any other information you can.

Price

Whether you are charging hourly, weekly, a fixed price or a range of costs, the price needs to be clearly outlined in the contract. It also needs to be clear whether the price is an estimate or a set flat rate. Include payment terms such as how you want to get paid (i.e. check, credit card), whether a deposit is required, and when the final amount is due. If you will be collecting progress payments, outline that here. You may want to mention something about revisions or change orders in this section as well.

Outside Scope

Take advantage of this section to protect yourself against scope creep and surprised / unhappy clients. If you ever have a dispute with a client who thought that something was included in the contract that actually wasn’t, that means your proposal isn’t clear enough. When in doubt, add those types of things to this outside scope section. Listing what is not included in the scope of the proposal might be as important as what is included. Outside of scope clearly shows the client what they are not getting and gives you a chance to upsell additional features or services. For example, you may want to upsell website maintenance on your proposal for a website. Or you could list all your other services even if they are unrelated.

Having a strong web development contract is important for both you and the client. It’s an opportunity to establish expectations and detail what exactly they are paying you to do. The contract will also protect you from unhappy clients and never-ending, scope-creep-ridden projects. Take time to do it right and make sure to have a contract signed for every web development project you start.