Contracts, CYA

Pavel Lutskovsky

It’s another Thursday. I’m neck deep in development and a a small job comes my way.  It’s so small that I can do it in 4 hours.  A carpenter’s equivalent of building a bookshelf.  Should I bother with a contract? What if it gets bigger? What if there’s scope creep? What if I don’t get paid?

The fun and exciting world of freelance became a lousy craphole where money talks and BS walks (especially when your clients lawyer up) and you get burned the first time.  Almost everyone gets burned. The smart ones only get burned once.  I’ve been burned. More than once.  Clients fail to pay and use your designs anyway, clients throw your work to someone else when they run out of money, clients try to change the scope of the project and don’t want to pay extra.  And I don’t blame them.  They’re out to make a buck any way they know how — just like me.  They don’t want to pay any more than they have to and if I’m dumb enough to work without a contract, I guess it’s on me.  Here, an ounce of prevention is worth a pound of cure.

So, rather than whine and complain, I started using a simple but effective contracts to make sure I’m protected, the client’s protected and no one feels like they’re stepping into an episode of Law and Order in the process.  Namely, I’m after defining the scope of the work, defining who own things when I’m done, how I am to be paid and how much.  There are a lot of other pieces that I could include, but they would not be in line with keeping things simple.

To further keep it simpler, I don’t charge the client for drawing up the contract (though some do and there are arguments for why they should). Granted, I’m not a lawyer (nor do I ever want to be one) and can’t say that these steps will prevent things from getting tense or prevent the client and I from disagreeing.  Rather, these steps give us some pieces to agree on so any disagreements are generally minor.

  1. Purpose.  A basic statement of the fact that someone is hiring you to do something specific (in my case develop a web application or web site)  won’t hurt.
  2. Description of work. I use whatever the client gave me in my initial interviews but in my words.  Their signature denotes agreement with my analysis.  I intentionally don’t include any language about scope creep or how to handle change orders.  I prefer to  discuss that as it comes up.  This is a good place to describe how the finished product is to be delivered.
  3. Content ownership. There’s a lot of argument within the development community about site ownership and copyrights.  I prefer the KISS approach (Keep It Simple Stupid).  The client owns the content once I’m paid.  Yes, I use the “work for hire” method.  Yes, I could follow along with the copyright train and give the client the rights to the work if I wanted.  But then comes the inevitable explaining of what that means to them and how they should treat the work if they want changes made.  If I lock them in, they’ll grudgingly come back to me.  If I don’t, they’ll happily come back to me for future changes because they don’t feel like I tried to pull some legaleze on them.
  4. Payments. I’ve done time and materials, I’ve done project fee, I’ve done share of profits.  Whatever your choice is, document accordingly.  If you have an hourly rate, write it down. If you want a retainer, write it down. If you’re going to bill the client every two weeks, put it in the contract.  If you expect those invoices to be filled by 30 days, put that in the contract.  If you plan on charging a penalty for non-payment, put it in the contract.  It doesn’t have to be complicated, but it prevents an unpleasant surprise when the client calls wondering why they owe you so much and why they should pay before the site is done.
  5. Development schedule.  This one can get tricky because you may feel like you’re locking yourself in and not everything is in your control.  I avoid the “locked in” feeling by giving myself a margin of error – 20% is reasonable, I think.  If you’re not great at estimating — pad your time more; you’ll get better.  I further put the client at ease by giving myself a penalty for exceeding the deadline.

If you’d like a sample copy to use, let me know, I’ll email you a copy under GPL.


One Response to “Contracts, CYA”

  • Tim E. Says:

    Thanks for writing this, I’ve been struggling with writing contracts and this article answered many questions. Could you send me a sample copy? Thanks.

Leave a Reply