How not to get screwed by your client when you’re contracting
By: Richardson Dackam
Tags: Design, Business, Web Development, Contactmonkey, Freelancing

How not to get screwed by your client when you’re contracting

I got screwed by ContactMonkey.com and its founder. This is an article about how you can avoid this from happening to you.

ContactMonkey, currently owes me a large sum of money that they refuse to pay, because they don’t plan to use my code. That’s unfair, I know but even worse; The problem is that they did use some of the code I built for them:

The feature I built for ContactMonkey

Why did they refuse to use my code?

Because they said that they’d noticed one security issue in it. This really matter because it asked this important question:

Should developers not be paid for their time when there’s a bug?

I believe that no developer write bugs intentionally. This is part of the development process. Bugs happen and even the best companies with the best engineers have to fix them. This is inevitable:

Apple Security Issue — Apple fixes Siri bug which let anyone access photos and contacts on a locked IPhone

Apple fixes Siri bug which let anyone access photos and contacts on a locked IPhone Facebook Security Breach — Indian techie, finds bug that let him hack anyone’s Facebook account

Bellow you’ll find a ten steps guide on how you can protect yourself from clients like him.

HOW NOT TO GET SCREWED BY YOUR CLIENTS IN 10 STEPS

1. Scope your client’s scope

If a client sends you a written scope of a project. Don’t assume it to be right, re-scope their scope. Most clients don’t understand some of the complexity involved with front-end or back-end and sometimes they’ll tell you things such as “All you need to do is put a button there.. its pretty simple”.

How I got screwed

I was working on top of someone else’s code, and the scope didn’t suggest that I would have to rewrite the entire logic of the application to make the feature work. He told me that he had reviewed the scope with his team and made it seem that it was a simple addition.

2. Don’t start any work until your client has sent you or signed a written agreement of the scope.

Some clients will tell you that an x or y feature was part of the scope after you deliver or would tell you that you’ve never agreed on a task after you deliver it, although you had that conversation.

How I got screwed

I very often emailed summary of our conversation but not everything was in writing, so there was a lot of “I said, you said” fights.

3. Get paid in advance for your time or a portion of your time (and your cost)

If you don’t want to end up in situations where you have to run after your clients all the time, and making sure that they pay you. Or end up with a client that refuses to pay you after the work is performed. Make sure they pay you in advance. Here a great article that can help you accomplish that:

Read “How do I get paid in advance? And why is it better for the client? By Christian from dangeroustactics.com”

How I got screwed

Our contract stated that I would be paid per hour and that ContactMonkey would pay me 15 days after I sent my invoice. Unfortunately, Scott would always be 3 to 10 days late on the payment schedule and sometime he would object to paying me or try to negotiate a discount after the work was performed.

4. Put everything in writing

You want to have records of your conversations. Also, if it’s in writing you can use this against them in court if it gets there.

How I got screwed

We had a lot of conversations over the phone, and some of the important thing we talked about weren’t in writing so he often denied the thing we had agreed upon.

5. Send Weekly Updates

You want to have a record of the work you’ve performed and the state of the application. Clients like to have an eye on the evolution of the project.

How I got screwed

I didn’t get screwed here. I always send weekly updates.

6. Protect yourself against being liable for issues and bugs

Some clients don’t understand that bugs are part of the development process and when they hire you to update an existing code, or build on top of it they are also taking a risk that some bugs will get introduced in the process.

How I got screwed

Well, He refuses to pay me because of a bug.

7. Never give an estimate without considering the time to QA

When a client ask you how long you think it’ll take to build a feature: Don’t give an estimate that doesn’t include QA. If you tell them three days Some client will expect the feature to be delivered and go live at 8 am on the third day without accounting for QA.

How I got screwed

I was often asked to give him a quick estimate of how long it would take to build a feature but often that “quick estimate” would end up becoming the expected estimate with QA included.

8. Clarify what getting paid for your time in exchange for money actually means to you client.

I can’t believe I had to make this a step… Some clients don’t understand that they can’t negotiate a discount once the work is delivered on an hourly based contract.

How I got screwed

As you may know already, once I delivered my work to ContactMonkey; Scott decided not to use the feature I built for them. My work was already performed, I had pushed my code, but he refused to pay me for the time I had put into this. Sometimes the client will engage in an hourly based contract without understanding the meaning of an hourly based contract, make it clear to them up front.

9. Run away from clients with unrealistic deadlines.

“All you have to do is add a button on that page, it’s simple”.

Sound familiar? These clients tends to have no respect for your work or the process and they tend to simplify every work you do into simple actions.

How I got screwed

After a few weeks working with the CEO of ContactMonkey, I noticed that he tended to simplify a lot of development work I had to do for him. When a client simplify your work, it tends to add a lot of stress. You always feel rushed because your client is expecting these items done quickly since they don’t understand what need to be done and that you’ll have to QA or test your work to deliver it.

10. Be aware of the red signs

Write down two lists: A list of things you like to see in your ideal clients, and a list of things you see in your worse clients. Whenever you’ll have new prospect, you’ll be able to use these lists to figure out if this client is a good fit for you and/or your company. If someone is already you’re client and you would like to know if you should continue working with them. Evaluate those client with that list and mark a red checkmark next to the negative point and a green checkmark next to the good one. You can use the negative checkmark as a reminder and a way for you to know when its time to let go of that client.

IDEAL CLIENTS ARE CLIENT THAT:

- Pay on time

- Respect and value my work

- Have realistic deadlines

- Work together to figure out ways to improve the delivery and/or a deadline

- Are clear with their expectations

- Stick to the scope of work agreed

- Understand that bugs are part of the development process

How I got screwed

I ended up with my worse type of clients:

MY WORSE CLIENTS ARE CLIENT THAT:

- Don’t pay on time

- Don’t value my work

- Have unrealistic deadlines

- Get upset over suggested deadlines.

- Are skeptical of your effort and hard work

- Work against you when you’re trying to help them scope the deadline

- Refuse to pay and constant payment negotiation

- Pretend you never said something that was mentioned in a weekly update

- Don’t respect the terms of a contract

- Stress you constantly

Conclusion

If you ever had to work on top of someone else’s code I highly recommend to follow the ten steps mentioned above. It will help you avoid these type of situations.

My advice to developers: Don’t work with clients like ContactMonkey.

Fool me once, shame on you. Fool me twice…

You can protect yourself from such events and build a long lasting relationship with your clients. I believe that all clients are not evil, but you need to be careful with the people you decide to get in business with and make sure to clarify your client expectations and yours.

After this experience, I would not recommend anyone to work with ContactMonkey or the current CEO. I do not support any value he represents and would not recommend their services for the same reason. A CEO of an internet business need to respect the developers that have helped him get richer and not treat them as a disposable asset.

If you like this post it would mean a lot to me if you hit the “recommend” button below.