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