Recently I had an unfriendly discussion with a client with him stating that "he can't pay for fixing the bugs in the application that I built for him".

His reason is simple:

  • I can't pay for bugs that you actually create.

He thinks that a bug in an application originates from the author so it should be the author's responsibility to fix it.

Do you share that idea?

+34  A: 

I feel that if you and the client work out the project requirements and scope up front, and execute that, then any bugs beyond that are either due to lack of testing, or simply unforseen.

In the case when its lack of testing, the client shouldn't have to pay for it.

When its a bug that no one could see happening, like a requirement that wasn't communicated correctly or simply changing functionality due to user needs, to me that is an added cost.

However, I feel that in your contract you should have a clause when it comes to maintenance. The client can't expect you to slave away at keeping code up to date, secure, and maintaining it day in day out without paying simply because you are 'the author'. Ask him this- when a book comes out in a new edition, is that book free? If a movie you already had on DVD comes out in a Special EDITION DVD, do you get that for free?

You have to establish these guidelines with the client up front so doing business is easier and there is an understanding from both parties when it comes to cost and invoicing.

It's give and take, and its the process of becoming a better developer if you care about your reputation. If you deliver a product that barely works, (and you care about word of mouth)- you need to do everything in your power to rectify the issues in a timely manner for free.

The better you get at planning projects up front, knowing the requirements, and staying in good, constant communication with the team(s) and client will help everything go a lot smoother.

In short, if you are half assing code, don't expect the client will feel they have to pay for it.

Mistakes in requirements and additional functionality are not "bugs" from a client-contractor perspective.
Adam Robinson
It's kind of a grey area to me. If it was explained to you that they wanted a feature to work 'like this', and you do that, but 'like this' meant some totally other way in their head- it's a fine line to say if it is paid or not. Probably a reduced rate if anything for that specific feature.
@Kevin: It should be written in the contract (or a contract-related document, like a requirements document). In that case, the determination of whether or not it's been paid for is, strictly speaking, the domain of the judiciary.
Adam Robinson
Yep, was just about to edit my comment and put that in but you beat me to it.
They can always try to find another developer to fix the bugs... I'm sure that won't be free.
Matthew Whited
Yep, I'm sure we've all inherited projects/legacy code before.. as fun as that is.
+15  A: 

If he's paying you to build reliable software, and you deliver buggy software...why should he have to pay you more to fix it (with the exception being functionality that was either neither in scope at the onset of the project or requirements that weren't communicated up front by the client)?

If I buy Microsoft Windows and Microsoft finds a security hole, I'm not charged a fee to download the patch. It is Microsoft's responsibility to fix the bug in the original software free of charge for me.

The same would go with buying a car. Toyota released "buggy" cars. They then recalled the cars and fixed the issue at no cost to the owner.

Justin Niessner
Downvoted? Can somebody let me know why? I don't think my answer is out of line...
Justin Niessner
I agree that when it is due to a lack of testing it should be fixed without extra cost.However who can test an app at a point he can say that there is no more bugs?The point is that any Project should have an end, and that end should be defined upfront.I feel that a project that you can't say when it is over is not a project.
Different situation. When you buy a copy of Windows from Microsoft, you're buying a copy of something Microsoft would have built anyway. In this case, the client isn't buying a copy of existing software - he's paying to have new software built.A more apt comparison - does Microsoft refuse to pay it's developers for time spent fixing bugs?
@BlackAura - I wouldn't consider it different at all. If I pay for a contractor to build me a house, I expect the house to be built correctly (and it's a one-off). If the construction fails because of somthing the contractor did...I damn well don't expect to pay him to fix it.
Justin Niessner
@BlackAuro - Not to mention that if we all stopped buying and paying for Windows...Microsoft definitely wouldn't keep creating it.
Justin Niessner
There is no requirement for Microsoft to fix a patch. They do this as a service to loyal customers. It's why they have the right to make their patches not work with stolen copies of their software. And why they can stop leasing patches after they end of life a product. If it is something small like getting rid of an easy memory leak that is one thing. If it is a ground up rewrite for new/changed requirements; I don’t see why the developer should fix that for free.
Matthew Whited
If something broke on my 20 year old toyoto, even due to a mechanical defect... they would NOT fix it for free. Warranty is important.
Robin Day
@Matthew Whited I agree. I wouldn't call a new/changed requirement a bug either. That's a change to the specification.
Justin Niessner
@Robin - You make a good point. A warranty period is important (I would say a product support lifetime for a software product...but the idea is similar).
Justin Niessner
@Justin: I wouldn't call new/changed requirements bugs either... but that doesn't stop the user/client from trying to do just that.
Matthew Whited
@Justin: "If the construction fails because of somthing the contractor did..." yes, but who is calling what a bug? If the plans for your house say "Parking Garage" you don't get to bitch and moan when the contractor builds a garage for a single car when you **obviously** wanted a double. You see this as a fault (bug), while the contractor/developer sees this as extra **billable** work resulting from a poorly stated requirement.
Binary Worrier
@Justin Niessner: I agree with your original post, but in saying so, I think that the development shop should pad their initial asking price with an "expected maintenance fee".
Jim G.
+1  A: 

I agree whole-heartedly with your client. If a builder built you a house but the foundations became unstable because they weren't built correctly - whose responsibility would it be? Certainly not yours.

You do have to draw the line as to "what is a bug." For example if a calculation isn't working correctly because the client changed his requirements on what that calculation should do - then, yes, the client should pay for it because the requirements changed.

This is where making sure you have an exact specification, and a set test sheet (with successful testing carried out and recorded by the client) works wonders.

Andy Shellam
why the downvote?
Andy Shellam
Exact specifications are not possible, period; and a candidate package will mostly fall short in stability and functionality. Software does not have a delivery date -- it has a life-cycle. Anyone that cuts corners is making old-school mistakes :P
Hassan Syed
You're close. You also need to draw the line in time. If you buy a house, the builder isn't on the hook forever. There is a warranty period. Once that period is over, then any change/update/bug fix has a cost.
Chris Lively
@ttmrichter - when did I say that it was possible to write bug-free software? @Hassan - you can write an exact spec at the time it's written and agreed with the client, any chances should then go through the same consultation process.
Andy Shellam
+9  A: 

The programmer is supposed to deliver the product with a reasonable quality. reasonable quality being a term that should be defined when taking the job.

If you keep your end of the bargain and bugs pop up later, then the client should pay. it is maintenance activity. Oherwise, you should work to get the software in good enough shape to be delivered

This is actualy what i think.
Put a clause in the contract that defines for up to how much months after delivery bugs are fixed for free. (name it warranty or something). If A client reports a bug after 1 month, I will fix it. If the same bug was reported after 13 months I would charge them. (unless they have a service contract off course)

there is no way to create a software or a script without bugs...

What kind of bugs are you talking about?

While it's certainly unlikely (and that unlikelihood grows as complexity increases), there's no technical reason that a particular bit of code can't be "bug free". That's a generalization that makes developers feel good and clients feel irritated.
Adam Robinson
But there is a mathmatical reason you can't prove that it is...
Actualy the bugs are not there yet, this is the problem.he expect me to fix every bug that might occure in the life time of the application whitout any extra cost.And no one can make an app without issues.
+1  A: 

Obviously it's the programmer who is creating most of the bugs. Of course there are bugs which are due to buggy libraries or wrong/ambiguous specifications. But since every programmers creates bugs, fixing bugs is part of the development cycle. So the client should pay for it. Perhaps unless it was due to gross negligence on your part. But mainly it depends on your contract. If you are payed by hour then the client should pay it, if you offered it for a fixed price, it's your fault.

If you were in a taxi and had an accident because the taxi manufacturer caused a safety issue with the vehicle, would you expect to have to foot the bill? No, you'd sue the hell out of the taxi company, who would in turn sue the hell out of the vehicle manufacturer. It's no different in software. If the developer used a buggy library, on his head be it. My 2p anyway.
Andy Shellam
This depends on whether or not the client is paying for a *product* or for *your time*. If it's the former, then you should have a contract that defines this relationship. If it's the latter, then (generally) the client is free to choose another developer to continue where you left off.
Adam Robinson
+1  A: 

Well, he did pay for the application, and that came from you.

This is why we have contracts and written agreements to say who is responsible for what in the development process.

If someone built me a house and then the roof started leaking the first time it rained, I would expect them to sort that out for me and I wouldn't expect to have to pay them for the privilege.

If someone built me a house and then a meteor hit the roof and put a big hole in it so it started leaking, that might be a different matter.

Ultimately there will always be bugs in software and how you deal with them really needs to be agreed with the client in advance- do they want to sign off and pay on the day and you consider the version they signed off on to be working, caveat emptor? Do they want to purchase support as part of the price and have any issues arising fixed by you as they come up? Who is responsible for QA on your work? Do you provide source code so they can take it to another developer if it runs into trouble?

All these things are reasons why you want to have a contract established ahead of time, so everyone knows where they stand.

Please do read the thread.There is no bug at this state of the project. neither him, nor me are able to find any other bug.The problem arise when it come to maintenance period after the project has been accepted by him.
At the time I posted this that wasn't clear at all. My point is that you establish an agreement for precisely this situation, so everyone knows where they stand and that they are getting what they pay for.
+3  A: 

Hard to answer without more context. If this is an hourly gig and you were rushed through even after warning them that quality and defect rate would become casualties, then you'd be justified in billing to fix bugs. If, on the other hand, there was a flat rate to deliver on a set of requirements, and you have not properly implemented them then you're going to be on the hook for the fix. Of course there are an overwhelming amount of less clear situations in between these two extremes, so without knowing the nature of your arrangement and the nature of the defects, its very hard to give a simple yes or no.

+1  A: 

Software in development phases is expected to have bugs. If the company is paying you a monthly/hourly rate to develop the program, then fixing those issues is paid time. If they are paying you an agreed price for the final product, then you're expected to provide a properly working result for that price.

+6  A: 

This is generally something that should be something governed by your contract.

One option is that once the client has "signed off" on the deliverable, then anything after that should (from a contractual perspective) be viewed as a modification, regardless of the change being made.

Another option could consider aberrant behavior (i.e. bugs) as part of the original scope, so that even after "sign off" you are contractually obligated to correct the defect.

This isn't a question that we can answer with any authority.

If this is a question asking for advise on establishing such a contract, then no, it isn't reasonable to expect the developer to fix every bug in the software without additional cost in perpetuity.

If this is a fixed-bid contract, then I would go for the first option I presented (after sign-off, it's the client's property and his responsibility to get it fixed; whether he chooses you or someone else to fix it and what to pay them is his prerogative). That being said, if there's a major defect in the system, then it's up to you to determine if the business relationship and potential reference with this client is worth the cost of absorbing (or discounting) the cost of fixing the bug yourself.

If the client is paying for your time (i.e. paying you an hourly rate), then the point is moot, since whatever work you do after "completion" would/should be billed at the agreed upon hourly rate.

Adam Robinson
I understand.The project is a fixed bid project: the one you get from GAF or RAC or whatever.I don't have any problem fixing bugs that arise before the application is delivered as i'm dedicated to that project.but imagine that a bug arise while you're working on another project? i guess no one would apreciate being in such situation.
@Diallo: Fixed-bid just means that you agree to deliver a *product* for a *price*, as opposed to being paid simply on your time (meaning that the price is already defined as being variable). If you haven't defined this in your contract, then it fall more towards option 1 (as you have his money, I assume, and you haven't agreed to do any additional work).
Adam Robinson
I don't have the money yet.but the discussion arised when he asked if i would correct the application after it has been release.I already proposed him a one month free maintenance period and he agreed so i guess there is no more problem.But i actualy ask this question for future project.
+2  A: 

The client should have tested the application more thoroughly before accepting it. If the client doesn't have enough knowledge to test, he/she should let it test by someone who does.

Just like in construction work, you let an independent inspector inspect the building, because you as a consume don't know what to look for.

Once the software is accepted and paid, there should be a maintenance contract, so that if any bugs appear (that neither the client and programmer were aware of), it can be fixed, depending on the type of maintenance contract (paid by hour, or monthly fee).

+1  A: 

Too many organizations skimp on testing, or any other quality activity. This seems particularly true of small contract development efforts, where a product is delivered to a single "customer". In these cases, code is written quickly, and pressed into service as soon as it is written. Such code tends to be sloppy, poorly designed, and incurs "technical debt." These are also the customers that are most likely to refuse to pay for "fixing bugs", but it is their own development and management process that is responsible for poor quality.

In cases such as these, the programmer should be paid for fixing bugs, but the more likely, and certainly justifiable, response is for the programmer to "bug out."

Cylon Cat
+2  A: 

The key here is how you define "bug". If the bug is a null ref because a dev missed a input check then it should be fixed for free.

If the bug is a missing feature because the customer did not explain his requirements or because of scope/feature creep that should not be done for free unless the deliverable is shrink wrap software being sold to multiple customers.

I have seen customers define bugs both ways.

I agree with you.
+55  A: 

Before offering an opinion on the origin of defects, it's worth stating that consulting projects are typically either time and materials or fixed bid.

In a time-and-materials arrangement, the client is aggreeing to pay for the time, effort, materials, libraries, etc necessary to achieve the quality desired. In this model, it's somewhat moot to discuss where the original of the defect lies unless the project is outside of its scope or estimated duration and the contract under which the consultant and client are engaged has specific quality metrics that have not been meet and the contract outlines penalities on the consulting party.

In a fixed bid project, the consulting party agrees to complete the project within a certain duration/cost and as such absorbs the cost of fixing any defects that fall within the scope of the effort.

That aside, it's important to realize that defects can originate as the result of many different kinds of mistakes:

  • Requirements gaps or errors
  • Poorly managed change control
  • Innapropriate design or architecture choices
  • Misunderstandings of the requirements or design
  • Technology limitations or constraints
  • Skill of the project team members
  • and others...

Many of these causes are not under the control of the consulting party, and as such it would seem unreasonable to place all of the responsibility to redress defects arising from these issues on the developer. In general, there is an expectation of good faith: developers don't add defects intentionally into the implementation to extract additional charges and clients provide the necessary information and access to staff to ensure that the project can be completed with reasonable quality.

+1. Very well said.
Adam Robinson
Fixed price contracts usually include a limited defect liability period too.
+2 if I could. Very well articulated!
Tim Post
+6  A: 

If the project is delivered on a fixed cost basis and you are still in a warranty period, this it is completely the responsibility of he developer. If you are out of the warranty period or if no warranty period was negotiated, it is at the programmer's discretion. Depending on certain factors (how will it affect your reputation, do you want more business from this customer, how much will it cost you to fix the bug), you might still want to do it.

In any case, if the contract was a time and materials (i.e. hourly) contract, then it is the responsibility of the client to pay the programmer for his time. This is based on the idea that if the bugs had been found when the system was first built, it would still have cost the client to have them fixed.

Jeff Hornby
+1  A: 

When you build a house you have proven engineering practices and very little flexibility in deviating from the original design. But software is more like an anthill than a house.

Given the number of permutations possible it does not make sense to say that bugs are the authors fault. Clients should specify their requirements and test the delivered software for compliance.

Morten Mertner
+1  A: 

The act of coding itself will introduce bugs. If he doesn't want any bugs, he would do things using a manual process. Almost any computer system can be replicated manually (by hand). It'll be slower for sure, but it's possible. Let the client try to do it that way for a few days and then I think he'll accept that some defects are inevitable because programming is hard.

+2  A: 

Just to make things clear.

I think that bugs exist in essence in any application (that don't mean that i don't create a robust software) it just mean that i build it to be robust but that i can't garantee it. So the step of a project is:

  1. Define the specs with the client
  2. Build the software and test it with the client to a point where no more critical bug is found.
  3. The client is happy :-)
  4. I get payed (everything that the client owe me).
  5. The application is released and i won't work on it unless the client pay (even thought i do it often, i don't feel like i'm obliged).
Often some bugs aren't found until a live situation. It is often wise to include a warranty in your application. You will fix bugs as part of the application for 1, 2, 3, months after release.
Robin Day
This is actualy what i offered to the client 1 month cost free maintenance period just to make him happy.
+2  A: 

I've always found the software development process to be a series of "gives and takes" between the developers and the client.

On one-hand the customer demands that code is bug-free, bug-free being defined by the constraints imposed by the requirements and the work environment.

For example, we wrote a label printing application, and the customer, 99% of the time printed less that 1,000 labels. One day they had an order that required a 1,000+ labels to be printed, needless to say, the printing didn't work as expected. They demanded we fix the problem, at no cost, because this was a bug! We went back and forth, and in hind-sight, it didn't really accomplish much. This was a rare instance, so I just should have bit it, fixed the problem, and attempted to recoup the cost somewhere else, maybe in a future feature.

On the other hand the customer demands that changes be implemented very quickly, one of the benefits of writing a custom software solution. In order to meet these demands we would often have to throw documentation and testing on the sacrificial altar of development. Now some people might say you can't do that ... or you shouldn't do it, and we try not to, but the customer ultimately pays the bills and we have to do what they say! Though, I always let them know that the changes haven't been fully tested, and they are usually quite understanding. In this case, they often are willing to pay for the bugs.

With those two cases in mind, I always strive to have a good and open relationship with the customer, explaining to them the "give and take" of custom software development. Sometimes the customer is just being a jerk, and at that point you need to reevaluate the relationship, other times, they are short on cash or their boss is being a jerk, these are the times to earn some customer goodwill and just fix the issue, free of charge.

Just my thoughts and experiences.

I'm not persuaded by the "customer ultimately pays the bills" argument. Indeed I'm repulsed by it.Change domains to, say, civil engineering. Engineering practices mandate a certain grade of steel or a certain ratio of rivets to spans (or whatever -- I'm not a civil engineer myself). The customer says "that's too expensive, use cheaper steel". Do you do it?Ultimately the customers want you to deliver everything for free. Do you do it?
+2  A: 

If it's shrink wrapped software, then you should release patches periodically -- for free.

If it's software with some kind of periodic license, then the client should be entitled to patches and support for the duration of the license.

If it's ad-hoc software, then "warranty" is the word you are looking for.

It's all about sensible business practices.

Leonardo Herrera
+1 Warranty! That was the word I was looking for! Fix stuff for free for a length of time. Then its chargeable.
Robin Day
+9  A: 

One word I didn't see while reading all the (good!) answers, is Acceptance Testing.

This is one of the things that protect both sides, and is customary in projects, so that both the customer/client and the software author(s) know the system they have delivered has began its operational life phase.

Without acceptance testing, it is usually a vague legal issue. When performing acceptance testing, the customer defines what they wish to test. The system has to perform their actions in a way that was defined in the requirements.

Acceptance testing exists in most types of engineering work. The contents of acceptance testing should be part of the contract, e.g. you should, as a software provider, mention that acceptance tests will be defined by the customer. In rare cases, both parties define the tests. However, you as a software provider may want to inspect them so that the requirements you have, and the acceptance tests, say the same thing.

In case there is a mismatch between requirements and the acceptance tests, it usually means the requirements weren't fully captured, or weren't captured correctly.

Legally, your contract should mention that the system is delivered after it has passed acceptance tests. Before it passes acceptance tests correctly, it is your responsibility to fix it. After the customer signed its approval, or after all tests pass correctly at the production site, the system has been delivered, and any changes would be the customers' to pay.

Regarding the specific type of bugs detected afterwards, I will not repeat what many others said, and I agree with others saying that major bugs should be voluntarily provided by the software provider, but this is just a personal opinion. Acceptance testing is the first barrier to check.

Etamar L.
+1  A: 

Be careful about that "fix [for free] every bug that might occure in the life time" in a contract. Let's say there is a new OS version on which your program doesn't work. Your client may be thinking that this is a bug in your software and you have to fix it for free! Seems irrational but it's not uncommon thinking. So definitely you have to add a time frame. At least. As others say, "small but forgotten by client features" or even "misunderstanding how feature should work (after tests/RUP iterations)" are not bugs and that should be clear on contract.

+1  A: 

All code has bugs in it. Even the greatest programmers with all the testing in the world will have bugs in their code. I would first make sure the client understands the difference between a bug and incorrect logic.

A bug is an error, flaw, mistake, failure, or fault in a computer program. See Wikipedia's definition. An example might be the user clicks to save a product and one of the fields is not persisted to the database. Or a calculation is performed and the result is incorrect.

Incorrect logic is when the clients expects something to happen but it does not. For example when a new product is added the client wants it automatically added to the storefront's latest item feed and given a 10 percent discount code for the first month.

When originally approaching the project you must make sure that the client gets a specification document and it clearly states all logic that will be created. I assume you will have done this, after all you must know everything you are building before costing it and building it. If you have this, when then client approaches you to say they expected the system to perform a certain task, you have a clear document which shows you were never informed of that business rule. This also protects the client as it gives them a check-list for ensuring everything they paid for is provided.

Finally, when the project is released, the client should be served with a 30 day sign off document. This gives them plenty of time to ensure everything is working and all specifications are met. After sign off, any problems with the code can be charged with a maintenance cost or package (unless business relations wish to intervene).

So in response to your question. Bugs will always exists, but the client is wrong to expect you to support his project for its lifetime at no cost. The issue is not with the code, and it's not with the client. It's with the clients expectations and the lack of specification and planning pre development. Sort these out and you should ensure you never have to face the problem again.

+1  A: 

You have to understand Bugs can arrise from any stage of the SDLC.

  1. Requirements Gathering
  2. Requirements Definition
  3. Design
  4. Detailed Design
  5. Coding
  6. Testing
  7. Deployment
  8. Maintenance

At any one stage so many things can go wrong, you have to define with your client upfront what you are willing for do at what cost. Also show your client that you will give warranty and support at different levels and at different costs. Don't let them portray it as simply fixing bugs, but instead as warranty.


As others have pointed out, there's a difference between someone paying for your time, and someone paying for a finished piece of work.

If someone is paying for your time, then they should understand that fixing bugs is one of the uses of that time.

However, if you've promised someone a working application, then it's your job to deliver it.

Now, there's a certain level of good faith here, and any reasonably-sized application has bugs. Certainly showstoppers mean that you haven't actually delivered what was promised, while at the same time, minor cosmetic issues may be more reasonable to have additional charges for. Also, there's a fine line between "bugs" and "feature requests" that has to be looked at.

But, at the end of the day, there's a communication happening here that's probably even more important than any of these considerations. Your client is telling you that the product you have delivered is unacceptable. This really means that there is a mismatch in the standards that you each have of the delivered product.

Now, if you're not being paid for time, and the delivered product does not do what is promised, you should probably fix the issues - as otherwise, you have not fulfilled your end of the contract.

But if his standards are actually unreasonable, and these are minor issues, you need to decide whether or not his continued business is worth the extra costs of dealing with him. Certainly in the future you should either adjust your estimates appropriately, or more specifically spell out what will be delivered (or possibly include a certain number of hours of minor bug-fixing, etc.). However, some customerrs just aren't worth it.

But before deciding that he's not worth it, also consider network effects and other related issues.

Or, to look at it another way, he is perfectly free to come to you and ask you to do bug fixes at no charge. You are perfectly free to either do them, or say no. You must both accept the consequences of these decisions, however.


This is why you make a detailed requirements doc. Where you clearly state the programs desired behavior given a set of inputs. The more detailed this is, the less likely there would be any discrepancy with any bugs that may arise.

For example if it is clearly stated that this section of the program will take in these values (given a desired set of values) and what it should do with values outside of that range. There is not a lot of room for someone to say that the bug was the developers fault. If the bug is the result of something that was not specified in the requirements doc.

Basically, if you clearly state what the program will do under this set of input values, and the person paying for the program agrees to it it is not the developers fault if bugs arise, and all of the requirements are met. On the other hand, if the program does not function as specified in the requirements doc then it is the developers fault, and they should be fixed.


Of course programmers create bugs, they create functioning software too.

If you get refusal of payment, then you're not under obligation to hand over the software. If you have already handed the software and the customer is refusing to fund bug fixing, then do a little soul searching and determine what is the right thing to do.

The contract may have lent itself to be more time-and-materials. If so, fixing the bugs without pay is only necessary if you feel your reputation is on the line. Otherwise, they paid for your time, and now they are asking for more time for free.

The contract may have lent itself to be more a fixed price contract. If so, fixing the bugs without pay is only necessary if the bug is conceptually a flaw in the original agreed deliverable. Otherwise, it is really an expansion of the scope of work.

So, what did you agree to, delivery of Software for Money or delivery of Time for Money? If you can't clearly answer the question, then you had a poorly thought out contract (and you will have to decide how much effort you are willing to donate to harbour good will before you must be paid (or cut your ties).

Edwin Buck

A bug can be defined as, "It doesn't work the way I thought it should". The reason for that is generally because the requirements for the feature were not clearly defined or the implementation does not match the specification.

Bugs happen when specifications aren't clear and proper testing doesn't occur. You can create software without bugs, but it requires better project & requirement management.

It can be done, but you must spend more time away from the code.

As someone told me once, "Better to spend three weeks debugging than waste a few hours in a meeting".


Someone cited Microsoft. IANAL but I don't think they must fix bugs (e.g. http://it.slashdot.org/story/10/04/15/1839236/Microsoft-Refuses-To-Patch-Rootkit-Compromised-XP-Machines http://support.microsoft.com/lifecycle/?LN=en-gb&C2=1173 and many others examples).

They fix bugs because it's economically an advantage.

The same should hold for the contractors: after the software is delivered to the client and accepted by the client it should be good in the state it is, any further work should be paid work. It's always better to state this in the contract (perhaps allowing a few months after delivery of free bug-fixing).