Charging for bugs found after delivery

If the question was not a part of the agreement, then it isn't covered within the agreement, and no agreement exists on it.

Is it a development bug? What control does/did the customer have within the definition of the input that you used?

Was it a rollout bug that made it's ugliness known as you put the programming under load? If so, the product isn't final and you must firm it up.

Was it a redundancy test bug? Did something happen in the marriage between yours and theirs? If so, was it something that you knew, or should have known? They came to you with a face that looked a whole lot like a customer. Did they incidentally "fail to mention" some critical truth that changes the parameters of the initial agreement? And, now you look like a clutz? Are you on the hook for a re-design and they are off laughing somewhere, because at least NOW you know what they want/need?

Is it original? Are you looking at the basis for the first upgrade? Is it "French Vanilla" when what they ordered was "Vanilla" (all the while hoping you would throw in the French Vanilla, just because...)?

How critical, in the 120 year scheme of things is this project and this customer to your business success? Wherever they fall on the scale, finally, is the answer to your question I believe. If, on this scale, they fall somewhere in the middle, pony up your half.

These are all the considerations that come to mind when putting together a service contract in my head when I read your question. They are, by no means, the full litany of what SHOULD be considered, but they do make up a pretty good starting point for discussion when you are creating a valid, legal, and useable Service Contract, I think. I hope this (slightly tongue-in-cheek)list helps you.

i think this is the best answer.

more especially, did the customer define an acceptance test as part of the contract and did the software pass it? [and did you think it passed the same suite before shipment!?]

i've seen it often that the customer has one picture in their mind of what the screens should look like and what functions they should provide, but there's a disconnect between even their mental picture and what they really need.

i once spent a few months designing MY view of what data input and query screens should look like for an application i had in mind. it ran to about 30-35 pages of screens. i labeled all screens and fields and cross-referenced and specified them.

when i was done, i showed my work to a world-class database architect and asked her if she could design a database to do what my screens wanted.

she looked through my pages for a while and replied, "of course i can.. you did virtually all of the design work for me!"

can you say that about your software? did the customer participate to that level?

some years later, i was on a team that was trying to get a software supplier to design an online database for our organization. i was given their initial design and asked to critique it. i made many recommendations and suggestions, virtually none of which were incorporated into their product.

we finally fired them. it turned out that they had designed their product for a different kind of user's needs and were trying to resell the basic engine, and our needs were quite different. it took several months of going ring- around-the-rosie before we realized their game and fired them. they were not interested in input or changes, just revenue.

it takes some introspection and self-awareness to make this kind of thing work out right. both the vendor AND the customer must have that awareness and communication for it to happen.

good luck to both, and all the best.
plusaf.com