Around a month ago I delivered a system to a client (aftermath mentioned in my journal).
They contacted me yesterday about a bug in the system, so I had a brief look at it and started thinking about what the problem could be.
I mailed them that I would not be able to look at it before today ( I am quite busy with other things).
So today a took a copy of their database, replicated the problem - and started to fix it - after about 5 hours of work, debugging and programming the bug was fixed to my understanding - so I made a PDF print and mailed it to the client explaining the fix and awaiting their acceptance. In the mail I included my price for the fix.
No long time after I received a mail addressing that the fix had a cost.
I find it difficult to assert when a bug fix should be free and when it should cost something - the client terminated their contract with me after the delivery of the complete system and the system went live about a month ago.
The client tells me that this is not the normal way and that the bug is an obvious bug.
I can accept and fix bugreports, made just after a delivery, perhaps for up to two weeks after, but I have no intention of delivering lifetime support for free.
The fix is a part of the system, which has no value as such to me currently since it is a part of the system, which was custom built for the client and it will not be generalized until I find the time to do so (or a another client to pay for it). This mean it will not generate any income for me by other means.
So I was thinking about making a policy for bugfixes and a special price, like first two weeks it is free and the price for bugfixes after this has a special low-rate.
But I see a few problems with this, then all bugs have to be discussed with the client whether that where in the spec, or not . whether they are a bug or a missing feature.
I don't deal with the financial aspects of my job, but I work closely with people who do. I'd suggest you define what sign off means more clearly: you say you "delivered a system". For me, that means they accepted what you produced.
But do you have legal proof that they did?
I expect software developers to work with their clients to define acceptance criteria. If this doesn't happen, anyone might end up dealing with the repercussions.
It's tough pulling together the legal resources to deal with a large company, but in my experience all such relationships share similar traits: precise contracts matter because they define relationships. Large companies need precision because they employ lots of people, often in undefined roles.
Decide what you want to achieve beforehand. Define the technical criteria that matter to your client. Then deliver.
Always allow your client to change their requirements, but explain the implications of this.
