Ask HN: Freelancer - do you charge for fixing bugs? or do it for free?

I charge. My basic process is I do the project, then allow for two rounds of revisions from the client included in the base price, and anything after that (including bug fixes) is charged by the hour. As long as they know this up front, they tend to be better about testing thoroughly so they can get the most out of those two rounds of revisions, and they also don't pitch a fit about having to pay for bug fixes.

Charge. And don't be apologetic about charging.

If you are time and materials, they pay (AKA you get paid by the hour worked). If you are fixed bid (AKA 100k for this project), you eat it. It is simple as that. It is all about risk, on time and materials, you are basically agreeing to the client taking the risk of cost overruns which usually results in a lower per hour cost. On fixed bid you are agreeing that you are going to take on that risk for the client. It usually comes at a price to the company (I triple my rate). If you are time and materials, ethically it is the clients responsibility to shoulder the risk and pay you for every hour worked.

If it's your own work, it's unethical to charge for fixing them, it's like doing bad work and getting paid for it, and then asking money to do what you actually receive money to do. Just do it right in he first place.

Your client can't really test your work like a pro (I guess if he could, he won't hire you in the first place), and that's not his task. to compare it: When an Automaker mess up, they recall all the cars, they won't ask you to pay for that. Everything else is greedy and unethical IMHO.

Of course, if the bugs are from someone else's work, you should charge to fix them.

I generally offer a period of support for fixes/changes after delivery. If the changes are small (< 15 mins) I batch them up and do them once, or twice, during the period. If they are truly bugs - as in, something's broken and it's my code's fault - I don't charge.

If they just changed their mind about how something should work, I charge.

Definitely, bug fixing = not enough testing. So you charge for testing in advance of for bug fixing afterwards - you choose :). I am talking about hourly payment here of course. If price if fixed... then you can't charge for it.

It's all about going with the flow.

For good customers, I actually offer good-faith, (virtually) unlimited free bugfixing within some reasonable time window (6 months, 1 year), for something that's genuinely a bug (and my fault that it's a bug). Ditto for any reasonable questions they may have. Heck I often throw in simple enhancements ("can you just change this piece of text here?") if it's really no skin off my back to make.

I also offer this policy up front, and include the very minimal time overhead that this involves (typically 5%, no more than 10% of the net development time until deployment & end of the initial contract) in determining my hourly rate for that customer, of course.

So for "good" customers, I find this policy really puts them at ease (especially in sensitive, first-time negotiations), and me too, frankly. Because if there's one thing I'm good at by this point, it's at estimating when project is reasonably stable and ready to ship (with minimal probability of serious unexpected behaviors or defects, post-release). And because buy far the biggest worry for them, after whether or not the initial release is going to be total junk for them, is the prospect of being held hostage by some mercenary developer for minor support / fixes.

And also, I find that simply conceding them the benefit of the doubt outright ("no problem - if it's a bug, let me know, I'll fix it") makes them much more willing to concede the benefit of the doubt the other way, when I explain to them that something they think is a bug isn't really a bug, but rather due to an ambiguity in specifications or some external factor, etc.

As for "bad" customers, well, different rules apply of course. But we try to minimize our involvement with them, anyway, now don't we.

Well, thanks everybody for your answers, I see that it's a bit of a tie on what would be the best way of handling this.

Probably I'll go somewhere in between and decide on a case by case basis.