Web Development·12,052 discussions

Charging for bugs found after delivery

Locked

I’ve just delivered a web application to a customer. During the development period we tested it and finally the customer payed for the whole project. Now if the customer finds new bugs and he didn’t sign an assistance agreement how do you usually behave, charge him hourly? Suggest him an assistance agreement? If little bugs are found just few days after the delivery you don’t charge him at all?
Thanks.

Nicola

Topic

I think it would be interesting …

In reply to Charging for bugs found after delivery

to see the rationale behind charging a customer for fixing bugs.

What was the agreement

In reply to Charging for bugs found after delivery

And how do you define bugs?

Did you do an acceptance test?

If it is a true bug – a function doesn’t work as designed – then you did not deliver what you promised, and you should be on the hook to fix it in a reasonably timely manner.

If it isn’t really a bug but a feature that the customer assumed would be there but wasn’t – an ommission or a mis-interpretation of the initial requirements – thats a negotiation – you probably want to meet them half way, unless the requirements were so clearly documented there was no room for interpretation – and I’ve never seen a document like that in my life.

If its a new feature that the customer just thought of but never mentioned in the requirements phase or the design phase, then its an enhancement and you should charge your regular hourly rate.

James

Agreement? What agreement?

In reply to What was the agreement

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.

amen

In reply to What was the agreement

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

on the verge of tears

In reply to amen

it makes me mad when companies that have enjoyed revenue from their software, attempt to plug it into a different company or industry without caring if it’ll work or not.

yes, charge after 60 days

In reply to Charging for bugs found after delivery

after 60 days of use, all programming errors should be worked out.

extra features should always be charged at the regular hourly rate.

I gather this is a significant sized project

In reply to Charging for bugs found after delivery

Part of the contract is a requirement on the client to provide detailed specs, detailed acceptance testing specs and detailed test data that should cover all good and bad data types and issues. Once all aspects have been tested, with the test data, and found to be working OK, client signs off on acceptance. Anything found after that is charged as it would have to be either a fault in the specs, the test specs, or the test data was not sufficient to properly test the product – all within the clients control.

Should, by some minor miracle, a fault be found that is NOT due to one of the above, then it is fixed free. Only known case was a printer interface code had a character missing and testing did not iclude printers. Next contract testing included printers.

Effectively we fix anything that is our fault, but not anything that could, and should have been tested by the client – if poor test then their bad luck. As we build to the set spec and the test specs, tests during the build are how errors are found.

with in 2 weeks I would

In reply to Charging for bugs found after delivery

At work and in my freelance contracts, I will normally fix any software bug if it pops up with in two weeks of project closing and as long as the code has not been “comprimised”, but I also include that in my standard contract. Anything beyond that they can sign a retainer agreement for that development or pay an hourly fee dependent on what the project is and what it is coded in.

just my $0.08

[Author]

Replies