I have a client that doesn't want to pay for the time that is spent fixing bugs, is this normal not bill clients for time that you had to deal with bugs?

SITUATION: I billed a long time client for a project and he noted that the bill was higher than usual so I let him know that it was because I ran into a bug that held me up for a bit.

He doesn't feel he should have to pay for that extra time because it's not his fault I made an error. He also said he asked around to other developers he knew and that they all said it shouldn't have taken me that long so he thought I was trying to cheat him out of his money.

There was not a specified amount of time that I had to stay under for this project, the client just thought the time was longer than it should have taken.

Is it typically the case that clients are not billed for time you get stuck on bugs?

  • 3
    Generally your contract should specify. We generally charge for bugs found and fixed before going live and then the company eats the cost for bugs after go live. Of course we often get into a "discussion" as to whether a particular item is a new feature or a bug.It is critical to help them make that distinction.
    – HLGEM
    Commented Aug 8, 2017 at 21:23
  • 2
    If you had an hourly contract they should pay. You should not have told them you hit a bug.
    – paparazzo
    Commented Aug 8, 2017 at 21:23
  • 5
    If you EVER have a client say they believe you are cheating them, you should drop them immediately. It will only get worse from there. I say this from experience. His "Developer Friends" are probably high school kids, too. Commented Aug 8, 2017 at 21:37
  • 1
    What country is this? In the US this is not normal. Bug fixing is part of software development and time/resources should be allotted properly for it.
    – Isaiah3015
    Commented Aug 8, 2017 at 22:27
  • 3
    A contract is a contract is a contract (and not only between ferengi). If he doesn't like the contract, he can do whatever your contract states to get out of it and hire one of the developers he knows. Can't talk about your rates, but its his faults if he didn't get counteroffers first. If his developers tell him, that they produce perfect code on the first attempt always, we know they are liars... Commented Aug 9, 2017 at 6:56

4 Answers 4


Notwithstanding some gross negligence taking place on the part of the developers, absolutely not. The client pays. Bug fixing is a normal component of any development cycle, along with QA efforts to flush bugs out.

Don't fall for it.

  • 1
    +1 The only time I would take the hit is when the bug is stupidly the developer's fault. Otherwise, bugs happen.
    – DTRT
    Commented Aug 9, 2017 at 14:24
  • 1
    @Johns-305 - While I'm not going to term it "stupidity," specifying that it was a "bug" that caused the increased time (easily interpreted as "I messed up the code" to the customer), basically offering TMI, was probably not a wise move by the OP. Commented Aug 9, 2017 at 15:11

Is it typically the case that clients are not billed for time you get stuck on bugs?

This could depend on what type of specific contract you had with that client. However you can think of bugs as a usual part of developing a project, so it "falls" within the time agreed for its development.

If you charge per hour, to say so, then it is the client that should pay it as it was part of the total time the project took. If you charge per project then you already have a fixed amount that the client will pay, no matter if you have endless bugs...

In future occasions, when asked why it took you longer to finish project, instead of saying it was because of "bugs" try explaining that "it was more complex than other projects". Every program has its level of difficulty and details, something that should be considered when planning to build one, and that is strongly related to the time it will take to make.


Fixed cost contracts bugs are on you, they are paying for the job, not your time. If the job is a billed hours job, then generally, the hours worked are the hours worked. Bug correction is part of all development. Bugs found by the client during acceptance, well, then it becomes kind of a professionalism question to me. I should have found that before I said we were good to go if it is truly a bug, so that would often be on me to fix, but legally, it would depend on how the contract was written. I personally would not stick my client for my error which I should have caught.

That all said, those general guides might blur depending on the size or nature of the bug. If caused by my own failure to understand or correctly implement the task, then at least a part of that burden should probably fall on me and I should eat at least a portion of the hours. If however the fix was required due to complexities of the base code or the task requirements, then that is an integration issue, not a bug, and should be relayed as such. If the issue is caused by client changing requirements, then they issue is a change in scope and even a fixed price client may well be expected to pay for that for changing the task and extending the project in doing so.

As GrayCygnus stated, wording is important, even with a client you feel comfortable with, especially if they are non-technical. All clients, when they hear "bug" hear "you made a mistake" and will not be overly happy about paying for your mistakes. But an integration challenge is a normal development step and scope change is always on them. I would however tend to agree with a comment, if a client accuses you, or even really hints at saying you have cheated them, then you need to clear the air, finish current contracts with them, and in all probability move on without further bids to that client.


As others have noted it's typical on hourly based work to bill for all time spent, including bug fixing, unless it's a situation where you were truly negligent in some way.

When I need to have this kind of discussion with my clients, I always make a few points.

  1. A "bug" is not a mistake by the programmer, it is a natural part of writing code and working on code. Nobody is shipping bug free code, from Apple to Microsoft to NASA, bugs happen regardless of the level of competence and amount invested in advanced testing.

  2. if your client has an employee working for them full time who either made an error or discovered an error in a business process, and then had to spend a day correcting it, (for example, a bookeeper finding a problem with the way taxes were applied in an accounting system, requiring the fixing of invoices one by one) the employer would not and could not withold pay for that day.

  3. related to number one, if you are to be responsible for all bugs and unable to bill for your time spent fixing them, you will need to spend a lot more time up front planning, designing and testing your code. This extra cost will typically be far more significant than the cost of squashing bugs as they appear, and it will slow down the speed at which you can deliver work.

  • Number 3 is a very good point!
    – Salivan
    Commented Jul 1, 2021 at 8:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .