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)!