This article by Hunter Jensen, CEO of Barefoot Solutions, was originally published in the January 2008 edition of PHP Architect, a print magazine for PHP Professionals. It is the second article in a five part series on some of the different legal issues surrounding the web development industry.

I was a young freelance PHP programmer studying at the University of Virginia. After many late nights coding, I had managed to save up enough money to move to San Diego upon graduation … or so I thought. About two months before graduation I received a phone call from my boss with some really bad news. He told me that the client had run out of money and refused to send payment. Then he tells me, “so I just can’t pay you”. And just like that my graduation nest egg disappeared into thin air.

I am undoubtedly not the only person reading this article that has been put in that position. I felt angry and helpless. I still had all the passwords. Should I take the site down? Hold it hostage for my measly ransom? Write a nasty message about them on the homepage? While those were tempting options, they were unethical, illegal, and ultimately just plain wrong. Instead I turned to the only thing that could protect me in that situation: my web development contract.

Before I go any further let me pronounce this disclaimer: I am not a lawyer and this should not be regarded as legal advice. I am a business owner that writes my own contracts and have successfully sued for breach of those contracts in American court. Over my years in business, my contracts have been tested and tweaked in a variety of situations, and this article represents what I have learned.
Many freelance or independent programmers do not bother with formal contracts. It is understandably a lot of trouble to try and write one, or a lot of money to pay a lawyer to draft one for you. Unfortunately though, having a rock solid contract is an absolutely crucial part of being an contract PHP programmer.

So why do you need a contract? Even though you may trust your client, it is amazing how quickly things can turn sour when money is involved. And although a verbal agreement is a legally enforceable contract, proving that it took place can be difficult. Developers need a contract because a good web development agreement provides the following benefits:

• It clarifies in writing the verbal agreement reached by the two parties.
• By law, copyright protection is automatically given to the author, but that is rarely what is desired when a client hires a web developer.
• It helps manage the expectations for the client and the developer.
• It protects both the client and the developer from unfair treatment if a project gets off track.
• Finally, contracts are the foundation of nearly every economy worldwide. Knowing that contracts are enforceable in a court of law makes it possible to do business with someone without having to trust them implicitly.

So now that we have covered why we need a contract, next we should ask how. For many freelance programmers, especially early on in your career, hiring a lawyer to draft a contract is not financially feasible. In order to save many billable hours, it is often a better solution to draft your own contract, and then have it reviewed by a legal professional. This last part is crucial so I will repeat it. Even if you get most of it right, you do not know the city, state, and/or federal laws well enough to write a bulletproof contract. Always have it reviewed by a legal professional. But with that being said, there are certainly some topics that need to be addressed in every complete web development contract.

Relation of Parties
This describes the relationship of the two entities, the client and the developer, that are signing the contract. There are several common relationships, which include employee/employer, licensor/licensee, or client/independent contractor. In my experience the most common relationship is that of an independent contractor. If you are brought on as an employee, it is fairly common for the government to require the employer to provide you with any number of benefits like health insurance or retirement plans. The licensor/licensee relationship used to be more popular than it is now for web development. This relationship heavily favors the licensor. Many developers have taken advantage of this relationship by creating custom built software for the client, and then licensing it both to the client and his competitors. While this may be legal, if the client is unaware of your intentions then it can be considered unethical and I wouldn’t imagine you would last in this business very long.

Finally is the independent contractor relationship. For the developer, this means that you have control over your own hours and schedule. For the client, this means that you are not required to provide employee benefits. This is appropriate in many web development situations.

Duties, Term, and Compensation

For the client, this may be the most important part of the contract. I have a standard contract that I use for most clients, and it references an attachment to cover the duties, term, and compensation because I generally need to rewrite that section specifically for every contract. It answers the questions:

• What will you be doing?
• For how long?
• And for how much?

The duties section is often called Scope of Services. This section covers exactly what it is you will be doing for your client. Are you simply doing PHP/MySQL programming? Or are you overseeing the entire project from start to finish, including requirements gathering, graphic design, system documentation, etc.? Does this contract include regular updates and maintenance after the delivery? While it is important to explain what you will be doing for your client, it is often just as important to outline what you will not be doing. This will avoid any surprises down the road.

The next section covers the term and termination of the agreement. The term will begin upon execution of the agreement (when both parties sign) and may be terminated on any number of conditions. Most clients that actually read their contract will not be comfortable with a contract that they cannot terminate. I generally will allow a client to terminate a contract with 10 days notice on the condition that my company is paid, per the attached rate schedule, for all work up to and including the last ten days. Further, I am able to terminate the contract with 10 days notice on the condition that I return any payment or deposit that I may have received.

Finally, you include the payment terms. There are a few questions that you need to cover in this section. First include how much you will be paid for this contract. If you bill on an hourly basis, include your hourly rate. If you bill differently for different services (graphic design vs. programming, e.g.), then include your entire rate schedule. Or if you prefer a fixed price model, include the total price that will be charged for the project. For fixed prices, I generally will reference requirements and specifications documents, explaining that the client will receive what is outlined in those documents for this price. I will then include my hourly rate schedule for any additional features which are added on in the middle of the project – and there always are. It is also wise to determine payment due dates (Net 15, Net 30, upon receipt) and late payment penalties.

Intellectual Property
You have a few different options for the intellectual property assignments in a web development contract. Usually, developers will explain here that all tasks, duties, results, inventions, and intellectual property are considered a “work for hire”. This means that the client gets intellectual property rights to everything created. There are a couple caveats to this however. First, you cannot assign intellectual property rights to any third party materials (like the framework you used to build the site). Second, you maintain that all intellectual property assignments for work that was conceived prior to the execution of this contract are maintained by the developer, but licensed to the client for unlimited use and in infinite duration. This is important as it will allow you to continue using the libraries of code that you have built over time while allowing the client to use and modify them as needed.

Confidentiality
This section of the agreement will often be changed based on the client’s level of paranoia. It is important to allow yourself the ability to communicate with other developers, designers, or anyone else on your team as to the nature of this project so that they can build it, even if the information is highly confidential. Otherwise, the developer agrees to keep all information received from the client confidential. It is advised to speak with the client about whether or not you can tell other potential clients that you are working with them. A developer’s portfolio can be his strongest asset, but some startups in super secret stealth mode will be upset over even the tiniest of transgressions. Speak to your client, and write this section according to their and your needs.

Warranty/Disclaimer
Including a warranty on your web project is fairly standard in most web development agreements. The main purpose is to give the client a time limit within which they should complete any testing and report any bugs. The developer cannot reasonably be expected to address bugs a year after the site was initially rolled out. Any time from 30 – 90 days is reasonable, depending on the size of the project.

Limitation of Liability
In this section the developer proclaims that they cannot be held liable for any loss of profit or revenue by the client associated with the development or operation of the website. This includes indemnifying the developer for any third party claims (lawsuits) associated with the development or operation of the website, or any claims on infringement of copyright or intellectual property rights.

Non-hire Provision
This section is easily forgotten in a web development contract, but to me has proven to be one of the most important. Very frequently after completion of large web projects, clients realize that they will need a full-time employee just to manage and update the system that was developed. Who better qualified for this job than one of the people that built it? This paragraph lays out the fact that the client cannot try to convince any employee or contractor of the developer to leave their job. Further, even if this employee or contractor leaves their job, the client will not be allowed to hire this person until after a given amount of time. Anywhere from 1 – 5 years is a reasonable number.

Legal Boilerplate
While I hope that thus far web development contracts seem approachable, it is an unavoidable fact that there will be some purely legal mumbo jumbo in any contract. Some of the boilerplate that is most common:

• Entire Understanding – This document and any documents referenced by this document represent the “Entire Understanding” of the agreement. No other documents or conversations can be acknowledged if a conflict should arise.
• Arbitration – Agree to try arbitration before going to court. If it works, it will save everyone involved some money on court costs and other legal fees.
• Choice of Law – What court of law shall govern the validity of the agreement. Generally, it will be the state where the developer resides.
• Modification or Amendment – Both parties must sign and date any modification or amendment of the agreement in order for it to be valid.
• Unenforceability of Provisions – If one portion of the contract ends up being unenforceable, then the entire contract is not rendered invalid – only the unenforceable portion.

While contracts can be overwhelming at first, hopefully you have seen that they can be manageable. Further, by signing a web development agreement and covering all of your bases, the risk for all parties is greatly reduced. Any savvy client or developer should always insist on a development agreement, and one which was reviewed by a legal professional.

Returning to the story from the beginning of this article – what did I do when I realized the developer was not going to pay me? I went back to my web development contract. Fortunately, a generous commerce law professor and the university student legal services had helped me draft the contract to begin with, so it and I were in pretty good shape. I filed a claim in the state of Virginia and represented myself in court. Using my web development contract and a series of paid invoices followed by a few unpaid ones, I was able to show an ongoing contractual relationship, and that he was delinquent in payment. I received the judgment for the full amount. Now actually collecting that judgment? That was not so easy, but is an article for another day.

Share this article