Leaving full-time employment means a lot more is on your plate. In addition to the actual work, you have to market yourself, find clients, and deal with the books.

Once you’ve found a client and want to start work you’ll have to sign a contract.

Contracts can be messy. They are written in a language that is intentionally difficult to understand. They also aim to explicitly cover extreme scenarios that are depressing to actually consider.

You shouldn’t start work without one, as it determines important things like:

  • What type of work does the client expect you to do?
  • Does that work have a warranty? What happens if bugs are found?
  • How do you invoice the client, and for how much?
  • What is the expectation around payment timeframe?
  • Who owns the product of your labor?
  • What happens if everything goes south?

Clients will typically have their own contract they want you to sign, however these are almost certainly entirely one-sided. They are looking out for your client’s best interest, not yours.

A good thing to understand is that contracts are negotiable. You can certainly push back and ask that certain things are stricken from the contract that you are not comfortable with.

I am not a lawyer, and I recommend having a lawyer review your contracts before you sign them. That said, this is a quick list of things you might look out for when reviewing a contract.

Payment Terms

You’ll often see items like “Net 30” or “Net 15” in regards to payment schedules. This is basically how long the client can wait to pay you for the work you do. I’ve heard for large clients you can have extremely large numbers like “Net 60”. Depending on the client your results may vary, but I strongly suggest shortening this to the quickest turnaround possible. Keep in mind that some clients may never pay, despite your best efforts. If you’ve done the work already, you don’t really have any leverage.

A number of my independent friends require 50% up-front and 50% upon completion. This works well if you have an established reputation and tend to sell blocks of your time.

Having a small amount paid as a deposit up-front can help weed out clients who won’t pay promptly in the first place.

Open Source

I noticed a “no open source” clause in a client contract once. This was obviously a mistake because the client was very open-source friendly and the project was built upon open-source. This is more of an indication that a lawyer prepared this without understanding the company (or worse, they just grabbed a template online without really understanding it).

Deliverables / Timeline

I try my best not to agree to specific deliverables, especially not when timeline is dictated as well. I prefer to work in time blocks, so a client can purchase a week or more of my time and I will do my best to achieve some goals in that timeframe.

The key thing to look out for here is to not put yourself at risk by agreeing to scope that is poorly defined.

I’m convinced humans are just terrible at estimating. Estimates are useful for getting a notion of how big or complex something is, but when you’re tying your livelihood to an estimate, you better be certain. Most times it is less risky to just commit to a time frame and let the client put whatever work they want in a queue. You just work through the queue of work, and whatever isn’t done, isn’t done.

Also of note is the deliverables section of a contract. Usually for programmers this is just the code you’ve written, but some clients also want documentation and any other artifacts you have created. I tend to cover this under hourly work, so there are no surprises at the end of a contract.

Who Owns the Product?

A key element in a contract is who owns the work you’re producing. Some work-for-hire contracts stipulate that the work you create is owned by the client. If the client fails to pay (or is extremely late in paying) you cannot just retract the work.

If you’re producing work for a client and it is stipulated in the contract that you own it until the client pays for it, then you have leverage that helps them pay.

“You don’t pay, you don’t get the software”.

Have Your Own Contracts

Sometimes it is handy to have your own contracts ready for your clients to sign instead. This doesn’t always work (bigger clients will want you to sign theirs) but it is a starting point.

Obie Fernandez, a well-known author and entrepreneur in the Ruby community, sells his MSA Template online. I’d recommend starting with something like this and consulting a lawyer for specifics in your situation (and to address any regional things you should be aware of).

One of the benefits of having an MSA (or Master Services Agreement) executed before any Statement of Work is that you can get things out of the way like hourly rate, payment terms, etc. before discussing the project and its timeline and deliverables. This can help a company become your client without having to commit to any financial transaction.

Be Ready To Walk Away

Sometimes you won’t be able to come to terms with a contract. If you stand firm on the things that are important to you, you should be willing to walk away from the contract if the client cannot agree.

Can’t I Just Start Programming Now?

It’s tempting to ignore this and do work based on good-will or existing relationships.

I hate this stuff as much as anyone, but it is important to cover yourself and not expose yourself to risk.

Once a contract is executed and out of the way, you can easily just drop it in a folder and hopefully never look at it again.

Then just focus on delivering great work for your new client.