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?