Freelance contracts: Covering the essentials

All the important points that need to be covered in a contract for freelance programming or design work.

By Donald Ritchie

Signing a contract

Photo: Stock.Xchng

In my previous article, I argued against having a formal contract for small software development or web design jobs. For a particularly complex or time-consuming project, a proper contract, drawn up by an attorney, will often be essential. But for most straightforward programming or design work, a simple exchange of letters or emails will usually be adequate - and just as legally binding.

Typically, the contractor will write to the client, setting out his or her terms of business. The client will reply, either accepting the terms as they are, or suggesting changes. Once all the points are agreed, the various letters or emails will together constitute the contract.

So what areas should such an exchange cover? In this article, I'll give you an overview of the points that a typical freelance contract should address. Treat this as a guide only. All projects are different, and there's no single set of terms and conditions that will cover every case. You'll also need to take account of the normal practices in your own country or region. For the most part, though, you should be able to use what follows as a starting point for any contract you need to write for straightforward freelance work.

Above all, be sure to take legal advice if you're in any doubt. While it won't usually be necessary to hire an attorney to actually draw up the contract, getting a lawyer's input could save you a lot of trouble later, especially where large amounts of money are involved or where the cost of failure is high.

Keep it personal

A key difference between a formal contract and a simple letter or email is that the latter is personal. It's a communication from someone (the contractor) to someone (the client). Thus, you might write: "Dear Jake, I am writing to you to set out our terms for the XXX project that we discussed. If these are acceptable to you, please write back to confirm your agreement." Note the use of "I", "our", "we", "you" and "yours". No parties of the first part here.

Scope of work

One of the most important areas to cover is a statement of the actual work to be done. Ideally, you'll already have a written specification or some other document that sets out the scope of the work. This needs to be both detailed and comprehensive. It must not only cover the end-user requirements for the finished product, but also deal with such issues as response times, security, maintenance, or whatever else is relevant in the particular case.

Usually, you won't need to paste this document into your contract letter. It will be enough to include a simple reference to it. For example: "The work that we will undertake is as described in the document XXX, dated .".

If the project is a particularly short and simple one - a few amendments to an existing site, for instance - you might feel you can rely on a verbal description: "We will undertake the work that we discussed in our meeting on the ". Even so, it would make sense to attach a note of the actual points that were agreed - just in case one or other party suffers a lapse of memory.

How much it will cost

Another crucial point is the fee that the contractor will charge for the work. For a fixed-price job, this will be the actual amount that's been agreed. If the work is to be done on a time-and-materials basis, it will be the hourly or daily rate.

In both cases, you also need to spell out the circumstances under which the amount might vary. For instance, the contractor will usually reserve the right to increase the fee if the client requests changes to the specification. To protect the client, the contract might state that any such additional fee has to be approved by the client in advance. For a contract lasting more than, say, one year, you might also include provision for an inflationary increase.

As well as the fee itself, the contract should also stipulate any other payments for which the client is liable, such as re-imbursement of travel expenses or software purchases.


You will need to agree the timing of the invoices. For a small or medium job, the freelancer might ask for several staged payments: so much at the start of the work, another installment at a given milestone, and the balance on completion, for example. For longer jobs, you might stipulate that you will invoice monthly, for the work that was actually done during the month. In the latter case, the client might reasonably expect to see timesheets or other records to support the number of hours being invoiced (although in my experience clients rarely ask for this).

Payment terms

Be sure to agree the time allowed between invoice and payment. Freelance developers and designers naturally want to get their hands on their money as soon as possible, and will often stipulate payment within, say, seven days of invoice. Clients, on the other hand, have to work within the constraints of their companies' accounting systems.

In many medium and large firms, payables are run on a monthly cycle, with invoices received by the end of one month being paid on a certain date in the following month. The client might be reluctant (or unable) to override this timetable just to meet the needs of the freelancer. In those cases, a payment term of 30 or even 45 days might be more usual.

What if you don't receive payment by the specified date? Should the contract state that interest will be charged on overdue invoices? Personally, I wouldn't take that route. If the client has an automated accounts payable system, the threat of interest won't make any difference to the timing of the payments. And, besides, collecting the interest will probably turn out to be more difficult than collecting the original amount. However, you should be guided in this matter by what is normal practice in the relevant industry and country.


If the invoices are subject to any kind of tax, this should be stated in the contract. This will most often apply to value-added tax (VAT) or its equivalent. Note that you don't need to specify the rate of tax, nor the manner in which it's applied. It will be enough to say something like: "All invoices are subject to VAT at the ruling rate."

Delivery dates

This will be another key point in the contract. As well as agreeing the actual dates by which various stages of the work will be completed, you need to spell out the consequences for missing those dates.

The contractors will usually want to cover themselves with a clause like this: "We will use our best endeavors to meet the agreed dates, but will not accept responsibility for any losses arising from our failure to do so resulting from circumstances beyond our control." The client, on the other hand, might wish to include penalty clauses for late delivery, something which most freelancers will resist. You will need to reach an agreement at a point between these extremes that will be acceptable to both parties.

(In my experience, clients hate it when work is delivered late. But what they hate much more is not being informed that the work will be delivered late. This is not a contractual issue, but it does serve as a reminder of the need to communicate with the client and to keep them up to date with the progress of the project at all times.)

Intellectual property rights

This is often the most contentious area in any contract for freelance design or programming work. Put simply, it's a question of who will own the rights in the finished product.

The client can reasonably expect to enjoy full intellectual property rights in the work. After all, they're the ones that will be paying for it. The work should belong to them, and they should be allowed to exploit it in any way they like. That includes adapting it, re-selling it, giving it away, or whatever else they want to do.

But the contractor might well have a problem with that. If I was to develop some software for you, it would probably incorporate various library routines or other generic code that I've already written, and which I would expect to use again in other projects. I don't want to abdicate my rights to re-use that code. As well, I might want to adapt some of the code that I develop specifically for your project, so that I can use it again elsewhere.

With careful wording, the contract should be able to meet both parties' needs. For example: "You will have full intellectual property rights in all work that we develop for you as part of the project . As an exception, we will retain the copyright in any general-purpose code that we provide for the project, such code to be clearly marked with our copyright notice. This provision will not prevent you from using or adapting that code, or from re-using it in other projects"

But it would also be reasonable to prohibit the client from re-selling the source of the relevant code. After all, you don't want the client to package up all your generic library routines to sell to your competitors.


Freelance developers and designers have a professional relationship with their clients. A fundamental point in such a relationship is respect for client confidentiality. There's no two ways about this. The contractor has a fundamental duty not to disclose information about the client company or their affairs to any third party. The only exception is where they are obliged to do so by law, for instance if they are required to supply information during a tax audit.

Arguably this duty of non-disclosure does not need to be written into the contract, as it can reasonably be assumed that it will apply in all cases. Nevertheless, the client might well insist on it being included. This is something that any reputable freelancer should readily agree to.

I've seen cases where the client has tried to stipulate an amount of money to be paid in the event of failure to observe a non-disclosure clause ("If you fail to respect our confidentiality, you must pay us X", where X is some ridiculously high amount.) This is not a good idea. The price tag for breaking confidentiality must depend on the actual loss that the client suffers as a result, if any. Ultimately, this will be determined by the courts.


If the contractor and the client are located in different countries, states or provinces, it's a good idea for the contract to stipulate which jurisdiction will apply in the event of disputes or misunderstandings: "This contract will be interpreted according to the laws of California", for example. If the parties are located within the same jurisdiction, it will be reasonable to assume that it is that jurisdiction that will apply.

Summing up

The contract terms that I've suggested in this article are similar to those that I've been using for many years in my own software development business. During those years, I've never had a serious contractual dispute with a client.

But do keep in mind what I said at the outset: If you're in any doubt about what the contract should contain - and especially if the project is a particularly big or expensive one - you should take proper legal advice. In many cases, though, this won't be necessary. By following the suggestions I've given here, you should be able to produce a perfectly adequate contract - one that will serve you well no matter what kind of freelance work you undertake.

March 2013

Please note: The information given on this site has been carefully checked and is believed to be correct, but no legal liability can be accepted for its use. Do not use code, components or techniques unless you are satisfied that they will work correctly with your sites or applications.

If you found this article useful, please tell your friends: