

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

Hi there,<p>I'm a freelancer part time and I'd like to know if you charge for the bugs that are found after you deliver the product or do you do it for free .<p>I'm working on a larger app that basically has new features added every 2 weeks and every 2 weeks is put in production. I'm not sure if after these are added and bugs are found I should charge for the fixes.
======
kls
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.

~~~
andrewtbham
i agree with kls... it depends on your initial agreement. i rarely do fixed
cost projects. i would only consider it if there is a solid specification,
which is rare. otherwise they will nickel and dime you to death. also on the
invoice, don't put "fixing bugs" or stuff like that... use words like "change"
"modify" etc.

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

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

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

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

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

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

------
bwh2
Charge. And don't be apologetic about charging.

