Hourly rates, legal threats, and how not to hire a freelancer

A few days ago, I received an email from a potential client for what would have been a pretty small, straightforward coding project. He informed me he found me through a tutorial I wrote about adding a widgetized footer to your WordPress theme. (Yes, I know it’s over three years old, but it’s still a very popular practice to include content in the footer of your site.) He wanted me to code something similar for his own site.

I responded saying that I could do it (I wrote a tutorial about it after all), told him about my hourly rate, and that it probably wouldn’t take more than a couple hours. A pretty reasonable estimate.

What he responded with

He came back saying that he doesn’t use a per hour fee for any graphic work. Okay, whatever, I’ll just multiply my hourly rate by the number of hours I estimate it will take and use that as a fixed rate. Simple.

He then went on to say how hourly rates were “really bad business sense” to pay based off of. That’s his opinion, and it’s understandable. Again, it’s not really a big deal for me to convert to a fixed rate. As I explained in my advanced hourly rate to fixed price conversion algorithm, it would’ve been the same price anyway.

The Red Flag

He then stated that using an hourly rate would assuredly “end up with a lawsuit” for me and how he was “forced to file in the past three occasions that [hourly rates] were used for work on [his] sites.”

Do you see the red flag in this statement? First of all, I might cut some slack if it was just one developer who he’d had a problem with and was forced to sue, but three suggests a pattern. A pattern that suggests the client is a little too trigger-happy on resorting to legal action against developers.

While this wasn’t a legal “threat” per se, it was more like “legal peacocking” (a term I just coined). I basically interpreted this as, “I’m not afraid to sue you. I’ve done it before and I’ll do it again.”

That’s fine if I was doing a terrible job, wasn’t living up to my end of the deal, and being an overall “developer from hell” (something I would never do, but still…). But before the project even started with absolutely nothing agreed upon yet, this was too much too soon.

Hourly rates are like blank checks

Okay, I get the concern over hourly rates. As a client, agreeing to pay hourly can be like writing a blank check. What if the developer came back with “oh yeah, this took me 52 hours so you owe me that times my hourly rate of $500. Pay up.”? You’d have a hard time proving that the developer didn’t work those hours unless you were supervising somehow.

This is what contracts are for. This is what estimates and client approvals are for. Clients need to get what they want and developers need to get paid. This protection goes both ways.

I’ve been working at a web design firm for the past couple months, and their billing process is pretty straightforward.

  • Client comes to us with their project.
  • We write a proposal, complete with the tasks that need to be completed.
  • Client approves the budget with agreed upon time estimates and hourly rates.
  • We can’t exceed hourly estimates without getting further client approval.
  • We finish the project, the client loves it, everybody is happy.

I could’ve got real fancy with a process map but you probably get the point. Hourly rates aren’t some archaic way of billing and they’re not “bad business sense.”

It’s actually pretty standard in this industry, and it doesn’t have to be a figurative blank check if you are thorough with your contracts. Something you should be doing anyway.

Contracts are not a magic solution

You can legally protect yourself with a clearly written contract complete with tasks, and associated time and billing estimates. And remember, a contract goes both ways, and both client and developer legally bound to carry it out unless there’s some sort of breach or you both agree to dissolve it.

However, a contract is not some magic pill that will make all your problems go away. While it helps define what should happen throughout a project, it doesn’t always get carried out. Either side could pull a vanishing act, work doesn’t get carried out to specification, payment isn’t made on time, the list goes on…

This issues can be magnified when you’re geographically located far away. If all other options were exhausted and you did have to meet in court, where would it take place? Would you have to fly out to their location? Would they have to fly out to yours? Who foots the airfare bill? It can get even worse if you’re not in the same country and local laws and other jurisdictions come into play.

Remember, you may be protected legally with a contract, but that won’t help you much with an absurdly difficult client. This is why keeping an eye out for red flags like this is so important.

While I highly doubt any of what I have described above would actually happen if I had taken on this project, why take the risk, especially for such a small job? It’s probably not worth the trouble.

The real issue

The issue is not converting my hourly rate into a fixed rate like the client wanted. It’s not hard for me to multiply my hourly rate by an estimated completion time to make a fixed rate. And it’s not my coding ability. It’s not hard for me to code a widgetized footer in a WordPress theme. These are not the issues.

The fact that this guy even hinted at a lawsuit (especially over such a minor project) before any work had even begun was a major red flag to say the least. I’m a busy guy, as you might have noticed from my lack of online activity in recent months. I have no time for anything more than minor coding projects, and definitely no time to waste in a courtroom.

The lesson

Clients, don’t scare off developers before the project has even begun. I know you want to protect your investments, but try not to mention the following words and phrases when trying to hire someone: lawsuit, hunt you down, chargeback, etc. Any developer who isn’t completely desperate for work will probably be running for the hills and you’ll likely have to settle for second-rate help.

Developers, keep an eye out for red flags when it comes to clients. Difficult clients can waste more time and energy than the contract is worth in dollars, and that’s never a good thing.

While there are a few classic warning signs of a potential troublesome client, the best advice I can give you is to just trust your instincts and use your experience to identify problems before they happen. You’ll be better off.

And for the clients out there, as always, do your due diligence when you’re choosing with a developer to work with. Check out their portfolio, read testimonials, get references, follow up on those, gauge reputation, you know the drill.

Join the Conversation


Leave a comment

Your email address will not be published. Required fields are marked *