Making my expectations known? Most freelancers tend to think that as hired guns, it’s not our job to set expectations. Instead, we work within their expectations. We’ll be code complete by a certain date. We’re going to be developing X, Y and Z features. We’ll throw in a month of maintenance, free of charge.

But like any contract, it takes two. In order for you to fulfill your end of the deal, your clients need to do more than sit back and dream of glory and riches.

I’ve worked on probably three dozen or so projects. It’s hard as hell to play hardball with clients, especially when your rent payment depends on that next invoice being paid. For me, I always felt that because someone was paying me – yes, me! – money, I was obliged to be their temporary slave. They ask me to jump, I ask them how high.

I’m a soft spoken, fear-of-confrontation kind of guy. There’s nothing that makes me reach for the Advil bottle more than the “I have some concerns. Call me.” emails I’ve received in the past. I’m also big on trying to reverse engineer people’s psyches, so I spent some time recently trying to figure out why this kept happening. And then it clicked.

It’s not about me!

A lot of client concerns usually stem from fear. Is this thing going to work? Am I blowing my savings? Wah-wah-wah-wah-wah. And when things aren’t looking up, they love bitching at their development team.

Doing client work is a lot like dating. It’s so great when all is good. And the second anyone starts doubting or fearing, you’re kicked to the couch.

“Pay your bills”

99% of client problems have to do with money. Your contracts with clients are bi-directional: The value they receive is the work you produce for them. The value you receive is cash. The moment this contract is violated, the offended party needs to take action.

If I’m not paid on time, I stop work. Immediately. Need a quick fix? Pay your bill, then we’ll talk. I also made sure my agreement states that I OWN ALL THE WORK UNTIL I’M PAID. If an invoice isn’t paid, revert their website to what it looked like before the invoice-in-question. Being able to tag invoice dates in git is awesome.

I give people one shot. If they are delinquent, I demand prepay for all future work. It makes sense – they can’t be trusted to pay on time any longer.

Oh yeah, and get a retainer before you start any new project.

“Be available when I need you”

Part of my job is to make sure I’m able to deliver things on time. Sometimes, I’m held back by a lack of information or because I need account information for an external API. But I can also be held back by long feedback loops. If your client isn’t available to verify and vet the work you deliver ASAP, then if and when there are changes, it’s going to take longer to backtrack and make any adjustments.

When your client takes too long to get back to you, your timeline (and budget) suffers. This kindles the flame for an eventual end-of-project explosion of anger, even though you’re not to blame.

I’m so stuck up on making sure my team and I aren’t set back that we built into Planscope, our project management app, a feature that will yell and scream every day until the deliverables you need tested or the information you need is complete.

“I can’t read your mind”

I often think that clients think I’m able to perform a Vulcan mind-meld and know exactly what they want and need. And this is another pain point, as oftentimes my understanding of a feature and a client’s understanding can be radically different.

Everyone screams Agile, but most clients still operate in a fixed bid mentality. And quite frankly, I get it. I don’t want my car salesman to be “agile”. I want to know exactly how much I’m going to pay because these things called budgets exist.

I’ve started emphasizing from the outset that I will be as flexible and accommodating as possible, but that adding stuff costs extra money (this should be common sense). I also let them know that I’m probably not seeing eye-to-eye with them about what they need built.

I once had a client who wanted users to be able to join groups. Fair enough, we’ll put a ‘Join Group’ or ‘Leave Group’ link on the group pages. While developing the feature, apparently he wanted it to work like LinkedIn groups – some groups are invite-only, some require a moderator to accept or reject pending memberships, and so on. Wow, talk about wanting a Lexus for the price of a Toyota!

This is one reason I don’t do fixed bids. Clients will always want the most elaborate features when the price is constant. Alternatively, I could have probably put together a very detailed software requirements spec in the estimation process, but I’d lose hundreds of hours (and thousands of dollars) doing that.

When estimating, ballpark everything. There’s no way you know exactly what your future client is thinking, and let her know that you’ve been bit in the past with the “Toyota vs. Lexus” problem. You understand their budget constraints, but put them in the driver’s seat. It’s up to them to prioritize accordingly and build the right features. And you have no problem estimating granular features, but you aren’t going to estimate “Message Board”.

You can also put together a detailed spec, wireframes, and so on, which will allow you to get a better understanding of what they need and maybe even a better estimate. The resulting material is extremely valuable for the client, so be sure to charge them for it. Don’t waste too much time estimating into oblivion!