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?

Why A Good Contract Is So Important

Our deck was original to the house and we’ve given it some TLC since we moved in.  This summer, however, the stairs started to rot and finally one gave way.  We contacted the contractor that had done some of the previous repairs on the deck for a quote to replace them.  How little did we know that the contractor had gone off the deep end and was setting everyone up for bad feelings and way too much stress.

When Total Bid does not mean Total Bid
The contractor came to the house the same day I called, and then gave us a bid in writing the next day.  I’ll skip the details, but here are the lines in question:

Total Bid:                        $x
To be paid at signing of contract:    $y
To be paid after completion of work:    $z = x-y

Total bid of $x, right?  Seems simple enough.  We added a power wash and some staining into the contract and that pushed the total up to $x + $600.  Well, we really screwed up and we wrote a check out for $x which the contractor promptly cashed the same day (Friday).

By Monday, we had a pile of stained lumber in our garage and the contractor was asking for another $500 to “make payroll”.  We promptly told him no, we’ve already paid more than we should have.  And that’s where it stood for a week as the contractor refused to return phone calls and emails.

When he finally met, he informed us that the total was $x + y + z and that we were trying to screw him out of the money he’d already put into the job.  So in his reality Total Bid was, at best, misleading and at worst, fraudulent (in my opinion).  I asked if he was willing to go to arbitration for the amount and he refused.  He was offended that we thought he was a liar and left in a huff.

Keep in mind, we’ve written software that does invoices and have been dealing with multi-million dollar projects for a large chuck of our careers!  I can’t imagine ever writing an invoice that was so bad that it confuses the client.

The Saga Continues
After thinking about it, we said the original bid was a little light so agreed to pay more.  He said great, but his ‘lawyer’ told him not to do any work without payment in-full for fear of us canceling a check before it was paid.  Never threaten geeks because we asked for the lawyers phone number and promptly did the reverse look-up to find out that the lawyer is a bankruptcy lawyer.

We paid the amount in full and he refuses to do the work until the check clears.  I have some serious doubts as to if he ever shows up again….

I’ve checked with the local Better Business Bureau (BBB).  He’s had 3 complaints in the past 24 months.  None of which were resolved.

The Lessons For Me as the Consumer
•    Check the BBB before deciding on a contractor.  It used to be you had to call their office and now it’s all online.  It’s not very hard to do and you should just do it.
•    Get multiple bids regardless of past experience with the contractor.  With a second or third bid I could have called his bluff when he said it was more money, or it could have proved to me, upfront, that his bid was too low and I would have flagged it

The Lessons for Me as a Contractor
Wow, where do I begin on this one.  My contracts are already much better than this guy’s half-pager.  Of course, in reality we’re talking about much bigger sums of money and longer periods of time, but that really doesn’t mean a thing.  A contract is the first place your customer is going to turn to in case of a dispute.  Other lessons:
•    Clearly define what work is to be done in as much detail as possible
•    List any assumptions and limitations before starting the work
•    Clearly define what the payment schedule is
•    Define how disputes are to be handled
•    Be as professional as possible and don’t let emotions get the best of me
•    Have a standard contract format you can use for everything
•    Oh, and don’t use “TOTAL BID” for anything other than the total.  🙂

I’m sure there are more lessons to be found in this story and I’ll be curious to hear your reaction to it as well.  As a contractor thankfully I have very few horror stories with clients having issues with work.  The one case that I can think of, the client has unrealistic expectations of what we (as software contractors) would do for them.  They expected us to do their end-user tech support since they had no one in-house to do it!

Their requirements document was a mere two paragraphs long with most of it being bullet points.  In their emails that kept using the term ‘easy’ when describing the project.  Needless to say, those two items are now ‘red flag’ items.