Ask HN: Client asked about paying for bug fixes
I had a client today asked me about why they should be paying for bug fixes when it seems like it should've been written correctly the first time. They were very understanding with the answer that I gave but I'm curious to know how others have dealt with it in other projects.
6 comments
My answer is always this. If I write a line of code, discover a bug, and fix it right away, it's part of the normal coding process and covered by the hourly/daily rate I've quoted the client. What difference does it make that the bug was found later or by another person?
Charge extra up front to write tests. The client gets higher quality code, and generally with less fixes needed.
That being said, there will always be issues until we have AI that writes AI that writes code (with the humans out of the loop).
That being said, there will always be issues until we have AI that writes AI that writes code (with the humans out of the loop).
I don't charge for bug fixes and generally try to do high fixed-fee engagements when possible. Hourly billing is hard to get right.
Unless you have a detailed requirements document, documented Test plan and a full Requirements Traceability Matrix (RTM), the client cannot really argue this. A lot of clients will not be able to tell the different between a "bug" and an "enhancement". If I had a penny for every time a client said "System does not work. This is an issue".....Well it is not an "issue". It is a functionality that doesn't exist as per the project scope and now needs to be implemented as a "Change Request" or "enhancement".
A good response would be, but "If it wasn't in the requirements, it didn't get coded."
We have to use that response alot when someone asks about a program that doesn't work the way they expect it to. Did you explicitly say that it needs to do this in the contract? No? Then it's not a bug, it's an enhancement.
We have to use that response alot when someone asks about a program that doesn't work the way they expect it to. Did you explicitly say that it needs to do this in the contract? No? Then it's not a bug, it's an enhancement.
If it's a time-based contract, then testing and bug-fixing is part of the billable time - it's a normal part of development. The client can decide how much testing and bug-fixing they want, often there is a point where the software is considered good enough to stop spending more expense on it.
For fixed-fee contracts, I usually include testing and bug-fixing in the quoted price, and make sure to include the time spent on that in the estimates. There has to be a sign-off time limit though (for example 1-2 months), during which the client is supposed to test the software to their satisfaction and after which newly discovered bugs are not included - otherwise a project can linger on forever in your schedule.
However with fixed-fee contracts the main difficulty is agreeing on what are bugs, and what are change requests if the initial plan was not detailed enough.
For fixed-fee contracts, I usually include testing and bug-fixing in the quoted price, and make sure to include the time spent on that in the estimates. There has to be a sign-off time limit though (for example 1-2 months), during which the client is supposed to test the software to their satisfaction and after which newly discovered bugs are not included - otherwise a project can linger on forever in your schedule.
However with fixed-fee contracts the main difficulty is agreeing on what are bugs, and what are change requests if the initial plan was not detailed enough.