Making websites and running a business are two very different things. Creative parts of the job are only one part of it; behind the scenes operations are the other half.

The thing with the business side of things is that you have to deal with customers. But customers are usually unaware of what kind of work it takes to make their website come to life. Misunderstandings can easily happen surrounding the topic of what exactly they’re paying for.

That’s where it’s useful to know what to consider when drafting a contract, and one specifically tailored towards WordPress web development. A good contract not only helps educate clients about what they get for services paid for (since that can be vague in the web development world), but it can also protect you, the developer, from lawsuits in the worst case scenario, or just plain difficult verbal conversations.

This article is not meant to be legal advice in any way (i.e. ask a lawyer, not me!). It is simply meant to bring up matters that you might want to consider when deciding what to include and what not to include in your WordPress web development contract.

1. Entitlements

Contracts can be scary to read, so outlining your customers’ entitlements as well as your own is a nice gesture of goodwill.

In the simplest example, you could outline payment terms, letting the client know that they don’t owe you X percent of a project fee until Y happens. Then they know they have weight in this as well and it’s not all risk on their part.

2. Copyright

Copyright is a topic with too many details to know what is right and what is wrong in every circumstance. Conditions can vary by country and not all of us feel as Disney does about preserving ownership of our artwork for generations beyond our lifetime.

However, it is important to decide what rights you will keep for your work, know what rights you can’t obtain and what rights you want to give your client. Will your client own all the .psd files after you are done building the site? Will they be able to manipulate files or send them to another designer to work with later?

If you’re custom coding something, will you retain the right to monetize your programming work for other clients, or will the code belong to the client absolutely?

What about attribution and authorship? Will you be allowed to name yourself as the author and creator of your work on the website you build, or will the client have that right?

In some cases it may just come down to preferences or compromises, and not necessarily an industry standard. But it doesn’t hurt to outline it all in a clear document.

If you hire subcontractors, how their terms will play into your own agreement with your client? It may be necessary to include subcontractors’ clauses in your contract, to pass on to the end client.

Finally, what if your client, unbeknownst to you, sends you copyrighted content or graphics to put on their website during development? As a professional you would not want to be in this position. It should be clear you aren’t responsible for copyright problems due to a client’s lack of research or awareness of this issue. In fact, your agreement could state that the client can’t send you copyrighted material of any kind to use on their site.

3. Outlining the Method of Development

Developing with WordPress is both a blessing and a curse. The blessing is the access to thousands of plugins and open source goodies that make your job easier and faster. The curse is that these plugins, codes, scripts and so on each have different authors; when you put them together, they may not mesh well. While everything might work fine at site launch, things can break with new software version releases.

The fact that you’ll be using a world-class system like WordPress, with all its infinite perks, can be made clear in your contract alongside the caveats with using such a system. Now your client can be mentally prepared, at least, for what ills may come in the future. But, they can also be told why the pros highly outweigh the cons in this scenario.

One way of wording this is to make it clear that you are not selling software to your client, but rather are selling the service to put together existing software that will turn into a website for them. The idea here is to take the emphasis off the misconceived notion that you created WordPress and all its plugins, and to show that you are simply employing the availability of existing software out there and using your time to do so. This is saving your client hundreds, if not thousands of dollars from having it otherwise be custom made. In short, you might want to say you are selling time, not a tangible product.

Otherwise, your client, who is probably clueless about programming, is only going to know that something you made them doesn’t work. “It’s broken,” they’ll tell you. You may know it’s a plugin author’s mistake, which is not your fault. Yet you’ll spend hours troubleshooting it. Your time is valuable. It’s your only currency as a freelancer. If you spend time fixing something broken, you need to be paid for it (if it’s not your fault).

4. Cross-Browser and Cross-Device Support

Some people use outdated or non-standards-compliant browsers (ahem, IE), which are next to impossible (or very annoying) to support in today’s web world. You may want to let your clients know how far you’ll go to make sure their site looks right on different browsers – even future ones.

Imagine what the web and devices will be like in another six months, one year, or two years. With retina HD displays coming out, the graphics we produced for the web a year or two ago are not cutting it anymore (they come out pixelated). Also, recall when Adobe Flash was used, and how quickly that method went out the door when the iPhone came out. Will you support the future changes needed for cross-device appearances?

5. Content Migration and Setup Limits

Formatting content takes a long time. Even with the WordPress WYSIWYG editor; it’s not a matter of copy and paste in all instances.

If you care at all about how a site looks, you will spend lots of precious minutes aligning photos and setting up heading tags to be just right. If you care about how a site is coded, you will also need to turn Microsoft Word’s <b> tags into <strong> tags, and <i> tags to <em> tags to match WordPress’s HTML5 structure. Not to mention, uploading photos alone is a huge time suck, and your clients probably will not re-size their 5,000 pixel-wide photos before sending them to you. If you also need to set up slideshows and other things that make up a website, you may want to set a limit on how much of this you will do. Remember, you are building this into a client-friendly content management system after all.

Don’t make the mistake of thinking your client will just magically know what it takes to set up their content. You may not expect them to send you thousands of pages. But content requirements can be surprising, and if it’s not clear how much of the work you’ll do in this area, your client can make a rather valid case that a website is not really a website until it has content in it. And then you’ll just have to do it (depending on your personality I guess…you probably won’t be policed into it, but you get what I mean).

So it’s important to consider this in your contract: will you upload 1,000 photos and format 300 pages, plus figure out which mislabeled photo goes on which page? And then will you embed YouTube videos? If this is a WordPress e-commerce site, will you set up products with 50 variations, each with their own pricing and SKU numbers? What about when a client notices a typo in their own content – are you going to fix those?

If you set up all content unconditionally, remember to consider the value of your price. The more time you spend on a project, the less you make. Eventually you could be taking the shirt off your back to please your client’s content requirements, which can be very high for some and very little for others.

Alternatively, you have your contract outline exactly how much work you will do for your quoted price. You could specify in detail the:

• Exact number of pages you will set up
• Number of blog categories you will make
• Number of photos you will upload
• Number of slideshows you will create
• Number of videos you will embed
• Exact SEO tasks you will perform (if any)

If you make web forms, those can be another time-consuming beast, especially for businesses that require registrations or applications. You can specify in your contract how many forms and how many fields within each form are allowed before surcharges apply. In this regard, also consider how many newsletter embed codes you will style (such as from MailChimp or Aweber).

6. Revisions

This one is very simple. How many times can your client ask you to make changes? If you don’t formalize revisions into official stages of a documented project management system, you could end up with several dozen emails asking you to change little things here and there, causing you to have to constantly re-do your work.

Aside from the mere number of revisions, it is important to consider in your contract the way revisions will be handled, the timeline limit for asking for revisions, and what counts as a revision request. My preference: all revision requests should be sent in one finalized, set in stone, no-turning-back list. Anything more – even an email a few days later with an “Oh I forgot” or an, “Oh I changed my mind” – is charged by the hour to go back and fix. The reason for this strictness? Going backwards takes up more time, and time is your only currency, remember?

7. Timeline

Timeline is crucial. Here’s why: clients are busy and can take a long time to get back to you. They don’t realize how much work it is on their part to produce a website. When they do finally get back to you, they might expect you to drop everything and quickly get their project done. But if they have delayed the project extensively (like months or even several weeks), by then you would have taken on other projects. You might need to re-establish a schedule of due dates with the client.

If you promise a client a site will be done within a certain time frame, that should come with stipulations and understandings about what the client will need to do on their part to help you meet your deadlines. You could say that they should get back to you within one week, and anything longer would mean you put their project aside and start working with new clients. When they finish their ‘homework,’ you can then re-schedule their entire project.

On this note, I strongly recommend you read our article about how to get clients to send you content on time. It has great ideas from the WordPress community. Content is usually the biggest holdup to getting a site done on schedule.

8. Hosting Requirements

Not everyone understands the requirements that WordPress needs to run optimally and even in general, what makes a good host and a bad one. Security, load time, and even customer service are just some of the oh-so important things to have. It can determine how much support you’re going to give your client down the road (which is not usually a fun area to increase billable hours).

While you shouldn’t ‘force’ your clients into using a particular host, you can try outlining the stipulations of hosting requirements you need to launch their site for them and for their site to run optimally.

9. Migration Mishaps

People often get excited when a web project is ready to go live. But they forget the launch process can sometimes be a bit rocky. In cases where you are changing hosts, and need to direct DNS name servers to the new host, or change any domain records, it will take a while for those records to propagate.

The scary thing is that changes to domain records can sometimes affect email (if the host is also the email provider, either for the old site set up, or for the new one).

If temporary site downtime means the client can lose customers, you’ll want to notify them of this before you start. If you put it in your contract, you could also release yourself from liability for losses that may occur as a result of migration and domain changes.

For example, what if they are not able to use email for a day because of mishaps in e-mail settings? You might have done everything right on your part, but John Doe at the company using his phone to check emails remotely doesn’t know how to change his Mail program settings and suddenly loses all communication with his team. Not to mention the sales inquiries and customer support emails that might get lost. A paid employee could have no tasks for a day! That represents a financial loss for a company.

Don’t be the person clients get mad at for this kind of thing! Plan in advance and put warnings in a contract that these circumstances could happen, and they can take time to iron out.

This is aside from the usual, easily fixable glitches that can happen when migrating a site, such as links being broken or leading to the development server, WordPress text widgets not appearing properly, plus other things that may not work the same on different server environments and require further testing after launch.

On a semi-related note, you may also want to consider the handling of ‘old’ website files you will overwrite during site migration. Whose responsibility will it be to backup and store a copy of those old files, if the client even wants them?

10. Security

We talked about security with regard to hosting requirements in your contract, but it could also be covered with regard to what happens after you launch a site for a client.

Case in point: let’s imagine a client decides not to purchase a backup plan for their site and security is not covered in your contract. Later their site gets hacked. You know who their first phone call is going to be to? You.

This is where your future support hours are going to come into play. Yes, you can charge your client for the time it takes to fix their site, but if they are uneducated about when your project duties end (e.g. once the project is launched), they can make it sound like it’s your duty to help them for free, since they got hacked and lost the huge investment they made into their website. They can blame you for WordPress security holes, which are not really your fault and are commonly dealt with using things like a backup system and strong passwords.

If you are a proponent of security, or just don’t want to have these conversations with clients, you may want to outline a few things relating to security in your web development contract. If it’s not as a stipulation of your service terms, then at least for client acknowledgement.

You could stipulate that the client should:

• Have a WordPress backup system in place or know the risks of not having one.
• Know the importance of strong passwords and understand you are not responsible if breaches of security happen as a result of them giving you passwords in order for you to do your job.
• Know that sites can break when updated and that yes, WordPress sites need updating from time to time.

You may also want to explain any fees you may charge to perform updates down the road, or to fix hacked sites.

11. Payment Terms

This is an obvious one. You will likely want to consider outlining the exact payment terms for your services in your contract. For example, you can say that a 50% deposit is due to start a project and that you won’t launch a site or deliver files until final payment is processed (or however you want to do it).

You may also want to mention a timeline for when all payments would be due, such as no later than 30 days after project completion. Or perhaps within a specific time frame in case the client delays their project, to protect your cash flow. More along these lines can be read on our article about getting clients to send you content on time.

On a related note, you may want to outline a refund policy. Since your work is time based, it can be hard to give refunds. There could be an explanation about whether refunds are allowed and under what circumstances. If a client does not like your artwork, is that a reason for requesting a refund? Or would they need a reason that is less subjective and more along the lines of your performance level? If you were late for example, do you have a guarantee for refunds?

12. Early Termination and Client Disappearances

It’s sad to say, but not all projects make it to the finish line, for various reasons. Clients may decide part way through the project that they don’t want a website anymore, they don’t like you anymore or they are going out of business. You may get seriously sick, decide the client is not making reasonable demands or need to cancel the project (for whatever reason).

It’s usually not a pretty situation and is difficult to deal with. Both parties often have a valid case. With some clients, the question of payment comes up.

You may consider including a clause that outlines a scenario where either party terminates the project. Who owes who money at that point, and how would the project value be calculated? Who keeps the files? Can design files be altered or distributed for other means by the client? How long after can the client request a refund, or project files, before you delete them (if you do that)?

Another thing that can be mentioned in this area is client unresponsiveness. What if a client pays a deposit on a site and somewhere in the process suddenly disappears for months? You don’t hear from them and wonder whether they are ever going to respond to emails and come back for what they paid for (it happens!).

In those cases, know your business will change over time. If clients come back a year later to ask a project to resume, you could be in a tough spot. Your prices may have changed, the work you did for them could be outdated and thus no longer usable, and sub contractors or employees who were aware of the project details could be gone, requiring a re-learning process.

Not only that, but you may have finished 90% of the work but only been paid for 50%. Should you have to go that long without being paid?

For these reasons there may need to be a stipulation that unresponsiveness from the client spanning a certain timeframe may automatically result in project termination, or some other consequence.

13. Possible Legal Action

This is important to bring up for a couple of reasons.

Firstly, if you and your client live in different cities, the party initiating legal action could ask the other person to travel to their location for a court appearance. You will not want to have to go through this travail or deal with this expense. Even if you win, and later pursue costs of your travel from the plaintiff, do you really want to waste your time doing all this? And if your client comes to your location and wins a court battle you’ve initiated, do you want them to be able claim travel expenses from you?

Not only that, the laws in your state or country and the laws in the state or country of your client may be different, and you will need to decide which ones will govern a legal case.

You can outline in your contract where legal action can take place and what laws will govern a possible dispute.

Secondly, how are you going to evaluate damages? Don’t forget part of your job is design and marketing, both of which are partially – if not mostly – art forms. Art is subjective and not easily quantifiable. You may charge a monetary amount on your work, but your client may claim the work you produced, or didn’t produce, cost them money, and thus try to sue you for more than the monetary value of what they paid you for.

So will the value of the project be related to time, money or the perceived value in what ‘could have been’ as a result of the project’s outcome? Hopefully you will work this out like mature adults, but if not, this should be made clear in your contract: what can you go after each other for if a serious battle ensues?

Thirdly, you likely won’t know the laws or ethical standards surrounding your client’s content or web graphics, especially related to their individual industries. You may unknowingly set up a site for them containing libelous or incorrect content. As previously mentioned, they may send you images to put on the site that are actually copyright protected without your knowledge. Maybe you slipped and caused a typo, but your client didn’t edit the site and approved its launch, so now that typo is a problem for them and they’re trying to lay blame for it.

Unless you love to argue, you won’t want to be part of any legal mumbo jumbo surrounding the implications of content. You want to make it clear that the site’s communication aspects are the client’s responsibility, not yours.

Conclusion

Remember that not everyone actually reads contracts. I don’t think this is healthy. It’s better to know what you’re paying for before you pay for it. That’s why I recommend:

1. Writing a contract in plain English that anyone can understand. What’s the point with legalese used in contracts anyway? What use is a contract that no one understands? I go through contracts in detail when they’re sent to me, and end up asking questions of business owners who paid a lawyer to draft them. Most can’t explain why certain clauses are in their own contracts. If you’re going to include a clause, give it a purpose. Explain its logic if you think it will bring up questions. You can ask a lawyer to look over your contract, but I would personally insist the writing remains readable to anyone aged at least 15, to ensure it will be understood.
2. Using normal sized fonts. I don’t understand why on earth fonts in contracts are so tiny. You want to encourage people to read the fine print, to avoid problems later. That is what contracts are for. If your contract is fair (see point 1 above), there is no reason to hide behind tiny-sized fonts.

We look forward to your own comments about things you think should be considered when drafting a WordPress development contract. Perhaps you’ve learned a few things the hard way that you’d like to share with the community. We can all benefit from your experience and start including special clauses in our own contracts, so please share your thoughts below!