<i>Don't compromise on price</i><p>Yes & no. Yes, if there's one thing you learn about pricing in consulting, it's "never ever cut rate" (you will never get a rate cut back). But the point in this article goes on to suggest that you should never back down from your assessment of what a project should cost, and that's going too far. Clients have budgets; sometimes those budgets are indeed too small for you to be productive, but other times they aren't and you should cut project scope to fit. Telling a client to spend more than they're comfortable spending is usually not a good strategy.<p><i>Don't do things for free.</i><p>No. When what a client needs is cheap and non-disruptive (and, one way to make it non-disruptive is to push the "free" back onto your schedule, which is coincidentally also a clean way to turn "free" into "paid" when the client balks at how long they'll have to wait), you should go ahead and do it to maintain the relationship. Doing favors for clients is, I promise you, cheaper than hiring salespeople. If you have a client that can't be trusted not to abuse favors, fire the client.<p>Lesson in human nature: there are few things you can do in a business relationship that are more offensive than charging for something that your counterparty doesn't expect to be charged for. So, one thing <i>never</i> to do: take an inbound request from a client, do the work with no contract, and then send an invoice.<p><i>Don't let clients pay you later</i><p>No, at least, not when you're working with companies of 100 or more people. You can negotiate payment terms, but you should learn how to sniff out payment processes that are nonnegotiable. Trying to convince a Fortune 500 company to pay you in installments or, worse, withholding work based on those installments is a recipe for disaster. It doesn't even help you; it just creates an opportunity for the client to continually second-guess whether they're getting value from the engagement. I expect 30 web developers to chime in here with client horror stories. My response to all of them will be the same: don't work as a web developer for small businesses. Also: some of your best clients will be the worst at handling payments. Build your business so that it can thrive even on slow payments.<p>Don't work for clients who can't be trusted to pay you. Real clients wouldn't dream of skipping out on a payment; what possible upside could there be to that? "Woopity-doo, we saved $30,000 and trashed our reputation and I got fired! Look how smart I am!"<p><i>Don't be at their beck and call</i><p>Sounds good to me. Set clear expectations. If you answer your emails at 9:00PM, clients will expect you to keep doing that. The flip side of this is that clients are usually entitled to set the terms on which you communicate, and if the client wants 10:00AM meetings, be prepared to roll out of bed 3 hours early to get on the call.<p><i>Don't part take in useless meetings</i><p>You should stay out of internal meetings; you shouldn't be a part of the weekly staff all-hands. But be aware that some "useless" internal meetings are resolving communications problems between stakeholders in your project. <i>You</i> don't get value out of those meetings, but your clients get value out of having you there. When skip out of the meeting, you become a shadowy figure or a weird black box that people resent and blame for communications issues. You can blame the client for being irrational about this (and subsequently lose the client), or, just get on the phone for the meeting.<p><i>Don't write lengthy proposals</i><p>And lose engagements to the consultancies that will.<p><i>Don't wait until client asks for an update</i><p>Yep. Daily status mail. I wish I could make myself do this reliably, because it's helped every time I've done it.<p><i>Stop caring about only the money</i><p>I didn't understand this point.<p><i>Don't do everything clients asks</i><p>This strikes me as a dumb reason to get fired by a client.