Should you charge a customer for bug fixes?

Question

I always have, either by factoring it into the cost initially or just charging by the hour. Upon talking with another developer, who is older and been around the industry longer than I have been, he said that wasn't honest. Usually with products I like to give a guarantee for a few weeks, but ongoing bug support for life seems a bit crazy to me. I know beforehand that there's going to be a bug, and if I am going to fix it, I'd think I should be paid for the time spent. Yes or no?

Edit: How about before the product is deployed. You see a bug or a feature that isn't working, do you charge for that time to fix it, or is that also free because it should have worked in the first place?

Answer 1

The company I work for doesn't charge for bug fixes. There is a very fine line between a feature request and a bug fix though.

If you are against that approach, an alternative that you may want to consider is a retainer contract. Sell X number of hours per month/year and then the customer can either sign-up and use that time for whatever they want or S.O.L.

Answer 2

For custom software, I think you need to have a clear specification, agreed to and signed off by the customer, at the start of a software project.

If a defect clashes with something which is in the specification, I believe that you are morally obligated to fix it at no cost; the software is essentially not fit for purpose and the customer didn't get what they paid for.

If a defect relates to something which isn't in the specification, then you could probably charge for it. Personally, I wouldn't feel comfortable charging for a defect fix; I take pride on what I do, and if there is a serious defect in my software I wouldn't feel comfortable putting my name against it.

Of course, this all requires the specification to be very clear. And with everything, there will always be a grey area.

The rules are of course quite different for off-the-shelf software.

Answer 3

Uhhh, no. Bug fixes are not features (though this line can get blurry, that is for you to decide.). Of course, that doesn't mean that they get every new version indefinitely, but if they found an obvious bug (and a few weeks is a paltry amount of time), you should fix it.

Look at it this way; if you got your brakes fixed, and then 2 months later they went out, would you not take it back to the person who did the job and expect a fix for no charge?

Answer 4

Ask yourself this question: is the software bespoke for that customer or are they buying it off-the-shelf?

If it's off-the-shelf, then charging for bugfixes is probably not the way to go. Those bugfixes are your responsibility and will benefit your other customers.

If it's a bespoke or highly customized solution, then it's pretty normal to charge T&M (time and materials) on custom modifications, including fixes--especially if those fixes relate to the customizations.

If there's a clear specification however you might be stuck with bugfixes but in my experience clear specifications are the exception rather than the norm so you'll find companies charge T&M on "support" simply because the customer doesn't really know what they want. Bugfixes and customized development all fit in the same bucket this way.

And like another poster said: it can be a very fine line between a bug fix and a feature request.

Answer 5

I would say 'No'. Charging for fixing bugs doesn't give you any incentive to write bug-free software.

Answer 6

It all depend. Normally, you don't want to charge the customer for bugs if you are still building his software. However, once the client have received, tested and approved the work you have done... you start charging.

It might sound dishonest but you are not working for free and you are worth something.

The only exception is when you are charging for a Product that you built and not a custom solution. Then it's your responsability to fix the bugs and make release to the client.

But even if you are the owner of a product, you might want to have different policy on "fixes". I've seen a lot of companies with a "Free updates for 1 year" included when selling the product.

Overall... make sure you get paid.

Answer 7

Yeah I tend to agree that unlimited support for life is a bit extreme. I have a similar process as you, however instead of a guarantee, I have a User Testing period where any bugs found in that time will be fixed, however anything found outside of that period has to be fixed in a future release which will involve a new scope and a new quote.

I generally find that as long as you are up front with your clients and let them know exactly what they are getting and what the exact terms of your work are then it goes a long way to avoiding any problems down the road.

Answer 8

Generally speaking...

We cover real bugs for 12 months.

Scope changes/feature requests are usually considered new work and are paid.

Answer 9

Most places I've worked have fixed bugs under a support contract after UAT.

Edit: Deciding how much to charge for a support contract is crucial to whether you make any money out of it or not. I've worked for one place who charged around £1k a month but had multiple developers working on fixing the bugs so just throwing money away, whereas others charge a lot of money for support contracts that are hardly used.

Answer 10

It depends on the type of software being sold. The software I deal with is specific to the industry and is sold commercially so has multiple clients but has a limited client base. The standard here is to charge an annual support and maintenance fee, usually around 20% of the sale price of the software package. This covers new releases, bug fixes and telephone/email support.

As with Anton, I have an issue with profiting from producing a sub-standard product (charging for bug fixes). Look at it from a business perspective: the easiest person to convince to give you money is the person that already has a history of giving you money - existing customers. A bug is actually an opportunity for communication with a customer where you can please them and potentially gain more business, either directly from them or via recommendations from them to their contacts. Ensure you don't pass up this important marketing opportunity just to squeeze a few extra dollars from them.

Answer 11

While most developers that I've talked to agree that bug-free is a myth since there's always room for improvements at the very least; there's a fine line between being driven to writing quality code and then charging for being intentionally bug ridden.

The model I would recommend for you is to use a grace period. Any bugs found with in 2 weeks of a release will be fixed for free (with a caveat about duration); however, anything not discovered until after that will be considered part of the next release and billable. The other thing to make clear here though is locking down your requirements and expectations so that your customers don't find "bugs" when in actuality they are looking for a new feature.

Answer 12

There are four classes of bugs:

---

• Showstopper - The bug prevents normal usage of primary program features, or causes any data loss
• Critical - Prevents normal usage of any requirement, and there is no workaround
• Non-critical - Prevents normal usage of a requirement but there is a workaround
• Superficial - Does not affect program operation (something is mis-spelled)

You should fix show-stoppers and critical bugs on your dime. Regarding your question as to what counts as your dime, you know your effective error rate. This should be figured into the price at the beginning of the project. Otherwise you are effectively working for free for a portion of the time. Accurate estimates and the ability to estimate how long it will take to develop a project and meet the requirements includes rigorous defect rate analysis and incorporation of your capability into the estimate. Debugging and testing are normal development processes, you don't need to think of debugging as a separate task that should be billed (or not) separately from development, it's part of development.

Non-critical bugs are a gray area. Depending on the customer and contract a valid choice might be to defer fixing it as long as the program meets all requirements given the workaround. But it's still a bug, it isn't intended functionality, and it affects a requirement, so in general I'd say fix them on your dime, but you don't need to go into 24/7 mode trying to get it fixed.

Spelling errors and other superficial bugs are something you should fix in the next release if the customer buys from you again. Otherwise, be sure your contract includes language that expresses such errors will be recorded and fixed in future updates, but are not part of the support contract.

At the end of the day, though, you need to include specific statements regarding your maintenance obligations in the contract.

Often a program written to spec will indicate what types of bugs will be fixed, and for how long after the software is delivered such support will be continued. If a bug is found after the first year of operation then it's likely to be superficial or non critical. So many maintenance obligations end a year after the final delivery.

It's really a contract issue, and the fact that you're asking means your contract isn't well defined.

Answer 13

No. If you do bug fixes for free, they will be happy and use you again in the future. Happy customers mean more money.

Answer 14

If the bug fix addresses an issue that does not meet the original requirements, then it should be done for free. If the bug fix represents a change to the original requirements, they should be charged double.

Answer 15

Many of these answers assume a waterfall, fixed-price project approach.

In the agile/TDD web development world that I live in, if I am working on the project T&M, all work is billable.

A bug can be looked at as a feature that hasn't been considered. And I would write a failing test to document the bug, then fix it and make the test pass. It's the same thing as creating a new feature, but in reverse order of implementation. We'd normally want to write the test before the implementation code.

No software is bug free; you cannot consider every future edge case.