How to avoid getting screwed by the clients you are trying to help

More than once I have been screwed by sidework, always when it comes to expectations and payments.

Has this happened to you?

The client thought that parts of the work you did was pro bono and now is refusing to pay the pretty invoice you whipped together, you - the developer - have already cut off a few hours of work that you have done because you preemptively knew they wouldn't pay for each and every hour. Now comes the final battle, you refuse to give them the final project till they pay the bill and they are sending you emails that you are holding what is justly theirs' "captive". Emotions end up running high and no one wins.

After this has happened a few times - I felt that I could share some of the processes that I have set into my client work to keep from getting screwed. Though this post is focused on the side of the developer, all of these recommendations have been engineered to protect both the client and the developer AND the relationship that is being forged. These recommendations help both sides have a clear understanding of deadlines and deliverables.

Do your research

There are always a few of those clients out there that no one has worked with but most have at least one project under their belt. With that knowledge ask around to your fellow community developers and find out more about the client and how they work, or even better, interview your client. It's okay to ask for references from past developers and vendors. Corporations do it, and so should you. Right out of the gate you may find that they have zero references - be cautious - or many people warning you against them - stay away! If you get these answers proceed at your own risk but don't be surprised when the situation starts going badly later.

You also may learn many good things about the client, a big benefit. Does that mean that you explicitly trust your new wonderful client? Nope. There are still steps you need to take to protect yourself but you can move forward knowing that other developers/vendors have worked with the client and come out the other side with a good word or two.

Don't rush the start

You may get an email or a call that your new client has a pressing deadline or immediately wants to meet and things need to move "fast". Don't let your client run your schedule, this is a good way to get into the fight of "you didn't deliver the product in time, I refuse to pay". If the client wants to move quickly that is fine, but make sure to still have all the legal protections before moving forward. If they want to move quickly then they will need to move quickly on signing the required paperwork.

Remember to keep good control on the timeline, if you can't get the project done in the required timeline pass up the project because you will only be setting yourself up for failure. As a side point, if the client does have a break neck pace in the requirements, it is okay to charge a rush fee. They won't enjoy it, but it is common practice for vendors across all industries. Their lack of planning or fast deadline is not your problem until you agree to it. You can always pass on the project and protect yourself. If you don't have the time to do things right, you don't have the time to do things at all.

The Paperwork

This is when you need a legal adviser to create a small suite of legal documents to protect both sides. Any good council can create a set of boilerplate documents that will do this. You may think this is a waste of time but clients will understand that they are dealing with a professional and there won't be any question as to the operating agreements set up from the beginning.

I've had some clients try to waive off legal documentation - BIG WARNING FLAGS. If a client doesn't like the boilerplate agreements that have been constructed then part of your bill will be legal fees as you draw up new documents with a lawyer and the client. Again, big companies do this daily and so should you. It is all about protecting you and the client.

Remember, when getting legal documents signed, get initials on each page and make sure that both parties have a copy with signatures. This way no one can say they didn't see a specific page and both parties can refer back to all documents at any time.

What are some of the documents you need?

I have 3 sets of legal documents that I use that include the following provisions and processes:

Work Agreement: This includes provisions such as payment schedule/plans, ip rights, reference to the project description/scope, prior work clauses, proprietary rights, mutual confidentiality, independent contractor provisions, indemnification clauses, termination clause, official notices definitions, successor agreements, and signatures.

Project Description: description, scope, deliverables, assumptions, organization of the project, roles, risks, and the workplan.

Change Request: description of the change, reason for the change, and impact of the change (financial/timelines/etc).

With these 3 sets of legal documents you set up a clear definition of where the project is going and what the client is paying for. Don't be too general in any of these points or you will only weaken the strength of your project planning. Again, get a lawyer to set up these documents for you in a boilerplate fashion that can be used for future projects.

The one form that I have enjoyed the most over the years has been the change request form. This immediately stops feature creep and makes the client aware of the impact of their requests. If you have a situation where clients "just ask for this one small change" and then later didn't think it was big enough to actually pay for, this form will resolve these common situations. Also, if the client decides to stop responding to you the week before launch, and has hurt their own schedule, prepare to write out a change request form and make sure they understand that you were held up by their inability to respond.

Do what you promise!

With all of your documentation and planning set in place the project is now yours to mess up - so don't! Keep to the schedules and deliverables that have been agreed upon between you and your client. If something needs to change on your side prepare to write out a change request and possibly make some concessions to the project.

Future development

After a project is complete you will usually have 2 reasons to revisit the code; bugs that were found and additional features. Both of these cases should be covered in your legal paperwork. Additional features can be treated as a new project, or if small enough, a change request. Bugs are difficult, especially if you there is a chance that the client has changed the source code. My way of handling bugs is to override whatever code may be currently on their system for our application with the final delivered code and then bug test from there. If it is a genuine bug then I am typically happy to fix the bug. However, this policy of overriding the code to the final delivered code has often revealed the same truth: The clients have changed the code and want you to fix the bug they introduced or the code they broke.

After I warn them that I will be doing the override many clients stop me and admit to their tinkering. At this point I consider the pro bono bug fix a change request or new project as I am now having to integrate an unknown amount of code that has been changed by them. Make sure to also check that they haven't changed versions on you. If the requirements were to develop in PHP4 and then they upgrade their servers to PHP5, the code migration may be significant and would be considered a change request or new project, not a bug. Make sure to have all this written into your agreements to protect yourself well into the future.

Making sure to mention...

Points that I make sure the client knows right from the beginning. These are also included in my legal paperwork so there is no confusion.

What meetings/phone calls are free and which aren't. I usually allow for some free meetings throughout the project for exploration, but I let them know from the beginning which will and will not be. This was created after I had a client that wanted an hour long phone meeting everyday while she was on her way home from the office. Kills my time and I make sure to charge for that time.

Delivering source code. Right from the beginning set up when source code will be delivered, because every client seems fearful that they will not receive their bought code. If it is based on payments, make sure to get the payment and it clears prior to delivery and remind the client that you, the developer, has a legal obligation to deliver.

I had one client that due to database requirements, required me to develop on their servers, meaning that a portion of source code lived on their servers at all times. In the end they got all the source code and tried to refuse payment. This matter was resolved with the worst possible situation, a lawyer had to step in. You want to only bring in a lawyer when all other possible efforts have been exhausted. I didn't take them to court or anything, I just had my lawyer send them one small letter reminding them that they were legally bound to make final payment. That was all the reminder that they needed to produce the final check. Sadly it came to that but some clients out there are only trying to look out for themselves and not the relationship.

Testing. Make sure to include testing into your project plan. If the client chooses to waive testing then make sure they understand that you are not responsible for possible bugs. Yes, bug testing should be part of development, however at the end of the project you should plan to really go through the code and make sure it is 100% covered. Again, if they don't want to pay for this time remove it from the project plan with provisions that found future bugs will be change requests and not covered under your guarantees.