You Have a Contract, Right?

Writing software for others can be a tricky profession.  The client often has totally unrealistic expectations on how software development works.  They give vague requirements (or none!) and expect you, the developer, to read their mind and produce an awesome application.  And therein lies the problem, because there’s a wide difference between their requirements (or lack thereof) and the finished project.  A handshake and a verbal agreement just isn’t good enough – You need to protect yourself (and the client) with a contract and spell everything out.

If you don’t have a contract already, my preferred place to begin is by going to Docracy (www.docracy.com) and looking up contracts.  These forms aren’t perfect, but they’ve been looked at by lawyers, and in-lieu of hiring your own lawyer, a heck of a lot cheaper.

The basic contract has little over a dozen sections.  I’ll just highlight a few of the sections that seem to grab peoples attention.

A payments section is obvious.  It gets into the details of how you’re getting paid.  More detail is good.  What’s the rate?  How long is it good for?  Is it a fixed bid?  What is the payment structure?  Do you have a separate rate for bug fixes and for how long?  When can you revisit rates?  Do you take check or credit card?  Do you have a fee for taking credit cards?

The expenses section should detail everything that you are paying for out of your own pocket (like computers, development software, etc.) and what you expect the client to reimburse you for.  This could include travel expenses, special services, software, or plugins required for the project, postage and courier services or any number of legitimate things.  The point is that you need to document it!

One section that has caused me some issues over the years was the intellectual property ownership section.  Every client wants to own the code you’ve written and this section gives any patents or trade secrets developed for the project to the client.  I have, as many consultants do, a stable of controls and classes that I reuse on nearly every project which really can’t be the clients’ property when the project is done.  This is where the consultant’s materials section comes into play.

Consultant’s materials are the tools, or pieces of code, that were in existence before the work began that you use to get the job done.  You can give the client nonexclusive rights to the software with some exceptions (spelled out of course), or you can attempt to retain the rights to your own software.  Regardless, this section should be read carefully so that you and the client thoroughly understand the implications.  It has been my experience that this section almost always needs an edit or two to satisfy everyone.

A lot of clients also require a confidentiality agreement section that says that you won’t talk about your work for the client to others without permission from the client.  Sometimes they also want a non-compete section stating that you won’t work on similar software for a certain number of years.  Make sure that you understand the implications of these sections because it might mean you lock yourself out of an industry!

All of the above is fairly generic and is applicable to nearly all contracts.  In my format, the exhibit document is where a bulk of the details occur.  Here is where I list my deliverables, the client deliverables (I don’t like doing graphics so I usually require that the client do them), a listing of any requirements that I’ve received so far (referencing emails and other documents if need be), assumptions that went into the bid, payment schedule and amounts and milestone dates.  As you can image, the exhibit may be much larger than the rest of the contract.

In the client deliverables section, I always state that the client is responsible for final application testing and that they are responsible for end-user support.  The reason that clause is in there is that a client assumed I was doing all the testing and was going to perform end-user support.  This is why writing everything down is so important!

One of the assumptions I generally add into my Xojo projects is that Xojo can actually do what I, and the client, assume it can do.  I only had one issue ever come up and because of that assumption we were able to negotiate a slightly higher contract price to purchase a pricey third-party control.

In the exhibit I add a section that describes how long after the final sign-off I’ll fix bugs for free.  I also state the rate for the following year on program changes (new functionality, not bugs) and when I can renegotiate pricing.  This section can be contentious.  I’ll fix true bugs for a long time, but a lot of times the client doesn’t understand what a bug really is and how it’s different from their poor (or nonexistent) requirements.  If you find a problem client, this will probably be one of the areas that causes you grief.

There’s a lot of information that will be in your contract.  It’s designed to protect you and your client against poor assumptions.  It provides a way for you to handle the client and set their expectations upfront.  In the long run, a good contract will be the roadmap of your projects.

Why have a contract?  Because not having one may cost you  a lot of money.  I turned down a project a few years ago because the prospective client balked at having to pay money up front.  In indignation he claimed in 30 years he’d never paid anyone up front.

He then proceeded to go through the rounds of contractors and they all turned him down for much the same reason.  Finally, he found a developer that was looking for some extra money but already had a full time job.  He did the work (without a contract and without any up front payment).  And, as you can imagine, the client shafted him in the end.  Said that it didn’t work as promised so therefore wasn’t going to pay.  The client was full of it because he walked away with the source and never looked back.

The developer lost thousands of dollars and had no way to enforce it since he didn’t have a contract in place.  Even having a contract won’t stop a client from not paying but at least with a contract the developer could have gone to small claims court to recover some of the money.  No contract meant no such recourse was available.

I think we all have contract horror stories.  Have any that you’d like to share?

4 thoughts on “You Have a Contract, Right?

  1. I’ve never had to worry about such things but questions comes to mind.

    Despite a contract how would a one person operation manage to get payment, if the customer is not local? With the net, the customer does not need to be in the same state or even country as the coder!

    You mention small claims court… but in which jurisdiction? Let’s say you were on the east coast and the customer on the west with no business presence in your state. Could you file in small claims outré in your state? Would it do any good?

    If you need to file in their jurisdiction across the opposite coast, would that not get awfully expensive because of travel or finding legal representation in that jurisdictions?

    Also what how do you handle timing issues, I would think there would be some causes in a contract for that as part of the deliverables. I know I have never been able to accurately judge how long anything non trivial would take me. How do you handle that?

    • About the only thing you can do for predicting deliverables is to have somewhat accurate estimates. Estimates are an art form all by themselves.

      We use the x3 rule. If we say a window will take 8 hours to code (long before we start the project) and then multiply by 3, that takes into account: the initial estimate, the time to code, the time to debug, the time to document, and then finally to make any changes the client wants. The client doesn’t always know what they want but they sure as hell can tell you what they don’t like. It happens.

      There are times I think a multiplier of 4 for complex tasks might make more sense but usually everything events out in the long run. As far as estimates go it’s always better to estimate high because clients HATE it when you come back saying you did a poor job of estimating a certain portion and now need to adjust it. It happens.

      The other obvious thing is to track your time and see how it compared to your estimate. Our product Task Timer came into being for this reason. Very helpful for us to have that information.

  2. The solution there is the one clause not mentioned in this post – choice of law and jurisdiction. This is simply a clause which says which jurisdictions law applies to the contract, and which court or courts have jurisdiction to hear cases – including cases of non-payment.

    Assuming it is a commercial contract rather than a consumer contract, you can make the court jurisdiction exclusive; in a consumer contract a lot of jurisdictions have consumer protection laws which over-rule an exclusive clause so in that case you want to make it inclusive – i.e. you can sue the other side in your local court, but they can sue you in theirs.

  3. Exactly! The last part of our current contract says where legal jurisdiction is. Most of the time we can set it to Kansas (where the corporation resides) but on occasion we’ve had to change that to the client’s state.

Comments are closed.