I did contract work for three or four years before I finally threw in the towel. It’s a lot of work, and very frustrating at times. I was very fortunate in that I never got screwed over, but many people have. Here’s my tips on the subject:
- Everything must be in writing. Especially the points in this list. You don’t need a contract; just make sure things such as pay, deadlines, support, and features are written down for reference in the future during a dispute.
- If you can get hourly pay where you bill them what you work, do it.
- If you can’t get hourly pay (99% of the time), take an entire extra day to think about how long the project will take in terms of hours. Don’t guesstimate – actually tally it up hour by hour, feature by feature. Add in 10% for the fact that you will have to break up the work over many days, slowing down your train of thought. Add in another 30% for bug fixes (even if you already added it in, trust me). Add in another 10% for features they are going to toss after you’ve already decided on a “final” version. Don’t tell them about any of this extra time you are calculating. Demand that many hours paid for the project. You will very likely still end up going over what you expect.
- Now work forwards and figure out by what day you will have the project completed. Add a week and round it forward to the nearest Tuesday and give them that day. Trust me. This gives you two extra weekends if you get caught up on something else.
- If you are being paid a lump sum, be paid 1/2 up front with the rest, in writing, to be given on the date agreed (the Tuesday mentioned). Make sure you have their name and address in case you have to use the court system. Remember that if they didn’t keep their end of the bargain and pay you what was agreed upon, they are committing intellectual property theft.
- Fight feature creep. Agree, in writing, on what constitutes “completion”. This requires a breakdown of all features and pages that must exist. Make sure it is very detailed, and make THEM do this work since creating the specifications for what the product should do is not your job! This will be the bible of your obligations to the other person. If they “forget” something, that’s not your problem. You will live and die by this list, and it will determine when you can say you are finished. Once you agreed on a price and start writing code this list is written in stone. Make sure you make this clear to them up front. Allowing them to add to this list is like letting them push back your pay day. This is not to say I never throw in free features, but at least I made them aware that next time, I might charge them.
- If they insist on adding a major deadline-altering feature that is not on your feature list, they have two options: pay you on the original date so long as the original pieces are done, or tack it on as an additional project after your second pay day. The point here is that you want to make sure feature creep is as expensive to them as it is to you. One “little” feature goes a long way in delaying a project if it happens 30 times. This sort of talk will make them think long and hard before making you add in a new feature. I always give this sort of warning up front, and my clients have been very good about refraining from wanting new features that they think of. They’ll even say, “We can do it on the next version or something…” If you let your clients walk on you, that is your fault.
- As for the rate to charge per hour, take your normal hourly salary that you get paid at your day job and multiply it by roughly two. Because you have to worry about your own taxes, the income is not steady, and the project might take longer than you anticipate, this is a very standard thing to do. Again, don’t reveal how you arrived at this number. Keep in mind that when you are first starting out, people will be weary of a high rate, so be sensitive to that when determining your price. As a point of reference, I had a friend who had to pay a sys admin $300 for two hours of work. Contract work is like that. A programmer should charge anywhere from $20/hr (high school student) and up. If you have kept a job as a professional programmer for long enough not to be “junior”, charge no less than $45 an hour.
- If you get a weird feeling that they can’t be trusted, don’t do it.
- Make it clear they are getting the code from you “as is”. They will know what this means. For your reference, it means you are not responsible for it breaking, being buggy, or not doing what they hoped. As a courtesy, I usually provide free bug fixes and support for the first two weeks. After that, I charge them hourly. Of course, all of this is also mentioned up front.
- Don’t agree to make something you aren’t sure you can do in time. If it’s beyond your skills, tell them. They will either find someone else, change the specs, or let you lower your rate in exchange for more time. Things are always negotiable, but never agree until you know you have sufficient time.
- If you are doing design work, agree up front on the number of “drafts” that will be reviewed before a final non-refundable revision is given. A typical number of drafts is two.
- I have used the “draft” concept with programming work as well. This means presenting them with a half-working “draft” 3/4 of the way into the project. This helps to ensure I create what they are expecting. I usually allow for minimal improvements or suggestions to be made at this point, but if a big change is made, I always point back to the original document and ask that I be compensated for the new work. Usually, you will find people just shout out cool features without thinking about if they are worth paying money for. Putting it into perspective will always help in keeping feature bloat down.
- Expect follow up support requests for months. Code is never 100% bug free. Just as an example, I had people emailing me about support requests three years later because they wanted the email address on the site changed! I only do free extended service when the bug is critical or due to my own oversight of the original specifications. The rest, I’m afraid, I can’t do for free. Neither should you. If you do it for free anyway, you’re either a chump or a really nice person — they’ll know the difference by this point. Let’s hope you do too.
- Make the customer happy. I know the above makes it sound like you’re going to be a jerk to the customer, but in honesty, a customer will be happiest knowing all of the little details up front. Keep an open and accommodating line of communication and I promise your clients will be pleased. Remember that it’s not about who-needs-who, but rather, it is a symbiotic relationship. Bending the agreement in their favor (doing touch up work for free) is at your discretion, but always make sure they realize you’re doing it because you are a nice person, not because you are obligated to. Remember that they aren’t going to give you money just because you ask, just as they shouldn’t expect you to give them work for free.
- Be prepared to get screwed if this is your first contract job. If you don’t know the ropes, you will underestimate the project difficulty, underestimate how often your client will change their mind, and miss your deadlines. Additionally, many of the hardliner approaches I list here will be more difficult when you have zero experience to prove you are trustworthy. On your first project, make sure you learn from your mistakes and be prepared to get stung a little. It’s normal.
I hope this helps! Don’t get scammed (NEVER WORK FOR FREE)!
Michi Kono's Blog 
“If they “forget” something, that’s not your problem… creating the specifications for what the product should do is not your job! …Once you agreed on a price and start writing code this list is written in stone. …my clients have been very good about refraining from wanting new features that they think of.”
Sounds to me like you’re not doing something right there. Have you considered trying iterative development? In my experience, clients are very frustrated with specification-based programming, because even when it does exactly what the specification says, the specification is a dead document that has become irrelevant in the intervening time.
Thank you for the excellent article and very sincere suggestions.
I did a contract project for the first time last summer, and did screw up a lot. :p Largely it’s because the wrong estimation of the project complexity and with no clear agreement on the specification. I also let the customer change too much and frequently about the features. Thankfully, they didn’t ask for a fixed deadline and finally the project was prolonged about 200% as it was planned to be complete.
Although the customer gave me some bonus (which is not in the contract) after the delivery but I don’t feel any good about it. I’m still in education so I think my model of planning and analyzing must change before I want to do some serious business. The biggest difference is in business, making things done in time is much more important than making things done beautifully, which is the model of learning and research (at lease, mine).
Opensource project might be the best place to fulfill my obsession to perfection.
J: A fully iterative development (see http://en.wikipedia.org/wiki/Iterative_and_incremental_development) is not something most clients will feel comfortable doing because it leaves open a lot of open doors. How can you give a hard deadline when neither of you know what exactly is expected? How can they, therefore, know what this application will end up costing them? What happens if half way in, your client decides to throw in a new feature that requires a redesign and recoding of 30% of the code written thus far? That sort of open ended incremental development only works in an environment where people are getting paid a salary and are happy to work into next month if necessarily. This is not the case with contract work. Setting exact specifications from the start allows everybody to be clear of the expecations and forces people to do the thinking up front instead of at the very last possible moment.
Interesting article and useful. Regarding the iterative development I agree with Michi, in a contracting environment it is not a viable solution. I work in an XP shop where we do iterative development and I wouldn’t have it any other way… in the corporate world. Along with that job I also do independent contracting and it’s just the opposite. If they don’t provide me a good spec up front, I don’t start the job. The only time I have done iterative work is when the entrepreneur agreed to pay me hourly rates on a bi-weekly basis so that I could develop prototypes and make changes as we went. The project lasted for a year and a half and at the end, the client never DID figure out what he wanted. Ultimately I think I would have done a better job for both of us had I forced him to sit down before-hand and decide exactly what it was he wanted.
Great article. You’re right on point in 98% there. Good job, I bookmarked it 😉
Another good one: keep a backup copy of all code you develop. You WILL get the call “we just deleted everything” or “our server just crashed” and you will be a total hero when you still have a copy and they don’t.
Having done contract work and not known to follow these directions, I can see the truth of most of your advice, minus forcing the client to draw up specifications. Most clients do not know what they want. You are much more qualified to design and IT system than the computer-illiterate people you are doing work for and your input into the specifications will both make the development smoother for you and make them more satisfied in the long run with the features that result.
On taking the iterative approach with contracting, I disagree with the original author and a couple of the comments so far on this thread; I think it can work. My experience has always been that things are going to change as the project is worked on. That’s just the nature of human organizations, and hence programming for human organizations. If you give the customer the peace of mind to know that you are receptive and reactive to those changes, in their favor, they are willing to pay more. They don’t want to be nickel and dimed to death, creating more paperwork, overrunning their budget and generally being a hassle. They would rather pay more up front, plan for it and get an iterative approach.
Companies want someone with your expertise in their corner. People want someone to come to with questions. Contracting is a people business. Yes, it’s important the customer understands what is going to happen. Yes, it’s important to get contracts signed and half the money up front. But it’s also important to fill the customer’s needs (however fluid they might be).
People (at least some of them) are willing to pay for service. You can find those people by telling them how much it is going to cost up front, and explaining that you do development in an iterative way. Then, you solve their problem. Businesses don’t just buy random code, they have a problem they want solved. If you solve that problem, your contract is a success. Most businessmen are willing to pay a good price for a service that completely solves their problem. They know their problem is in flux; they know that they may not have the solution at the time of the beginning of the project. They know they might find a better solution during development. They want that eventuality planned in. Tell them you are planning for change, and tell them that planning for it demands an iterative approach, and if they want a fixed price, it costs more because of the extra uncertainty. Explain the benefits of the system.
Also of note: escrow is awesome if the arbitration service is good, and terrible if it isn’t. Document absolutely all communications that occur with regards to a contract, and keep them on hand for at least a year afterwards. Forever is a good length to keep them, but whatever.
Also, I definitely have to second this: If it feels fishy, back out.
If you hear the words “entirely commission-based”, back out. If your employer mentions that they have done any stealing before and you’re not 300% sure that you’ll get the money (ergo it’s already in the hands of an escrow service you trust, or you already have it), back out.
Lastly, your estimate is probably wrong. Learn to accept that–try to identify why it goes wrong and by how much, and you’ll start learning to make it more accurate.
When asked for references, do you ever use your boss in your current salaried job? Even though I have an excellent rapport with mine, I’m not sure what he would think about me doing part time freelance work. Unfortunately, I’m just starting out in freelancing, so I don’t have any previous clients to draw upon, and so he’s in the best position to recommend my skills and experience.
You offer in the article very nice suggestions and down to earth advices. The agreed task list is the key element of the negotiation.
thanks! i like your post
my site: http://www.babylonlaw.com/ho-so-dang-ky-kinh-doanh.html
This helps a lot….thanks for putting it together. I am going for my first contract work from full time. Honestly I am quite scared. Its a W2 contract and I wasn’t able to get a lot info about the project out of the company but since the salary was soo good I took it anyways. But I really admire your advice…..especially the one…”be prepared to get stung”