I understand not charging for the initial meeting where we figure out if we're going to be able to work together, but after that if I'm in a meeting with the customer then it's billable.

That's part of the reason for charging by the hour. An hour of my time is worth X dollars, if the customer wants to pay that so that I can listen to he and his business partner argue about spending money to get more whiteboards in the meeting room (true story) then that's their choice.

It's tempting to devalue yourself when you're new to freelancing or consulting in order to get business. But I'd take it all back and do it the right way after what I've seen.

The first time you make a serious mistake or don't get paid because you didn't ask for payment up front, you learn the hard way that business is, in fact, brutal and you don't get anywhere by being accommodating or nice; you can only go far by being professional and proactive.

That being said, I find the formatting of this post a bit offputting. To my mind, the header usage clashes with the topic sentence accent (bolding) and I feel like I have trouble focusing on the sentiments.

Good content though; these points apply to all consulting positions, not just developers, although that's certainly the target audience on HN. I note that this piece also doesn't mention what GroupTalent does, which I think is a subtle but effective way of being "above the fray".

Good work again guys.

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.

Don't do things for free.

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.

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 never to do: take an inbound request from a client, do the work with no contract, and then send an invoice.

Don't let clients pay you later

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.

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!"

Don't be at their beck and call

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.

Don't part take in useless meetings

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. You 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.

Don't write lengthy proposals

And lose engagements to the consultancies that will.

Don't wait until client asks for an update

Yep. Daily status mail. I wish I could make myself do this reliably, because it's helped every time I've done it.

Stop caring about only the money

I didn't understand this point.

Don't do everything clients asks

This strikes me as a dumb reason to get fired by a client.

And while I already know the answers to my questions, because they are meant to be more rhetorical, they may try rephrasing those points for that seemingly direct contradiction.

You're absolutely right, but I want to put it another way. I actively price in "one extra thing" for every project. This way, when a client asks for an extra tweak there or a small extra feature there, I don't feel bad because I already priced that in and the client feels good because they think they're getting a bonus freebie.

Virtually ever client asks for a little extra and since I already priced it in, I have no qualms with providing it. Everybody walks away happy.