Client doesn't want to bill us for bugs caused by our own mistakes

In an unwieldy project such as the one I’m involved in, we sometimes create our own bugs as side effects for fixing issues the client wanted to be fixed. On a rare occasion we break something in the code (hey, everyone makes mistakes) and we work quickly to restore it again. The time here may total several hours in a single week.

Our client says that this time should not be counted towards their invoice. (they are paying by the hour) Is this generally acceptable practice? How would you feel if your client doesn’t want to be billed for hours you wasted fixing bugs that you accidentally produced?

My company never bills for that.
When we introduce a bug it’s our fault, ergo we should fix it at our own cost.

If you ask me to fix your windshild wipers, and I somehow manage to break your window in the process, wouldn’t you expect me to pay for that?

The problem we have is figuring out exactly which mistakes completely fall on our part and which weren’t. There were many instances where other bugs were unforeseen in showing up after we completed a task.

No offence, but you didn’t foresee them, maybe somebody else would have (and I’m not saying I would, I know the scenario… been there, done that, bought the t-shirt …)

You should have an allowance for that built into your rate so that you don’t have to charge separately for it.

We get paid to do something right the first time. If the customer agrees that they are responsible for testing, that offloads some of the project cost to them, so we do bill for bug fixes found during testing. But we don’t bill if the area under discussion should have been coded properly in the first place; in other words, bill if there’s a disagreement on the spec or for code that wasn’t written at all (since you would have charged to create it the first time anyway), but don’t code for reworks when you screw something up that you wrote.

If you charged me to fix a bug or feature that did not work correctly to scope I would not only contest the charge with you but be extremely unlikely to consider you for a future project.

Delivering a project that works is what people pay for. No one can find every bug in advance and obviously if the bug fix includes changing scope to have another result it’s not a bug anymore but if something is broken that should be a problem you jump to fix. If bugs are taking enough time away to really impact your bottom line you may want to take a second look at your review / QA process.

All software has bugs in it no matter how careful you are. There are actual formulae for estimating how many undiscovered bugs probably exist in a program.

The best you can do is to take into account that you will need to spend a certain amount of time on bug fixes after the event and factor that into your original pricing - that’s what all professional programmers do.

You created the bug then you fix it at no extra cost. I think thats only fair.


I would like to know that formulae.

Based on my past projects, 20-25% is a good number to go by. This covers either bugs that may come up, or little usability issues. You cover yourself in case things go wrong and if all is well, you make a few extra bucks.

Doing it this way is much better than arguing with your client for the extra hours (or sometimes even minutes).

All bugs originating from original programming, should be fixed free of cost. That’s my opinion of course.

I agree with above, coz every bug got from programer.

Think about this from a clients point of view ( the windshield theory )

Bugs should dissapear with a minimum of fuss, especially free from whining from developers about lost time fixing them. The idea is that you give the client the feeling that the software you are working on is functional/fixable and reliable, not bug filled/difficult to fix.

If they think the latter, they may consider replacing 1. you or 2. the software or 3. both.

The idea is that you keep the client, and recoup the ‘lost’ time in the future ( if you didn’t already have this time budgeted for in your quote/hourly rate, which is a more professional approach to the situation)

You shouldn’t charge for bug fixes for certain contract models. If you build them a product that doesn’t match what was agreed upon in the contract (aka, it has a bug that shouldn’t be there), that’s your fault and you are obligated to fix it. If you don’t do any sort of testing, those bugs are going to show up after the end of the contract.

Obviously the real question here is if the product is considered “finished.” Once it reaches that state, bug fixes are free. Before that you’re still building the product so you can charge for that time.

This is also for a boutique / freelance point of view. The rules change for a professional web firm.

I’m sorry I would have to agree 110% with the customer. If you are the programmer/designer and you didn’t do your job correctly which resulted in errors in the product they purchased, you should be 100% responsible for fixing those problems for the customer.

Can you imagin what would happen if Microsoft started charging us for their mistakes? The entire world would be in debt. It just wouldn’t make any since. I would never charge a customer for mistakes that I make, in fact, I’m not even sure that its 100% legal to do, depending on where you live.

If I sent someone a bill for my mistakes, and they refused to pay it, and it went to court, I’m pretty sure the judges around here would throw me out on the curb.

I agree, the bug should be fixed at no additional cost to the customer and quickly. On the developer’s side of things always undertake alpha and beta testing and make an costing alowance for them and the associated bug corrections. The great thing is you now have some experience on how long it takes so you can start to factor that in your next quotation.

Certainly all professional developers AND PROFESSIONAL CLIENTS know that software development inevitably involves debugging. In a fixed-bid project, it doesn’t really matter because the vendor has to fix everything at the agreed rate. But on an hourly rate, most professional developers [that work with experienced clients] charge for hours worked regardless of whether they were working on bugs or not.

I agree with the above comment that there will always be bugs, and that you can estimate how much debugging will be necessary. Why would this NOT be part of the billable hours? Is the expectation that the developers should never make an error or cause a new bug while fixing an old one? That’s not realistic.

What clients look for is a developer who writes good quality code that is easy to maintain and debug, and who keeps bugs to a minimum by using best practices and simple programming skills. If a developer of mine constantly introduces new bugs and makes a mess, I don’t consider whether I should pay for his/her time, I consider whether I need a better developer.

As always, there are plenty of less experienced clients doing lower-value projects who say ‘I’m not paying for your bugs’ but in the real world of software development, bugs are part of the game.

Our clients do pay for bug fixes - but we are open with the cause and fix so they are aware of what is being done. We also go a step further and if unable to fix a bug in a reasonable amount of time we actually pay the client.

What Sagewing says is true. No bugs are not realistic and is part of life. On hourly rate contract they are payable, just like anything else you do. And for fixed bid projects, bug fixing should be included in the estimate.