Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

So I just started freelancing both in desktop/web development and this client who already accepted my work, and payed me keeps coming back at me each time he finds a bug etc. And I have found myself spending more time than I thought fixing them for free. Is this alright, or should I start charging a support fee? Which is the best way to deal with fixes on a supposedly accepted and completed work?

share|improve this question
4  
For the serious bugs, there is usually 'hell to pay', so I guess hell pays for them. –  Tim Post Jan 4 '11 at 13:16
    
What do you mean by "bug etc."? There's a difference between bugs and further work not involving bugs. –  David Thornley Jan 4 '11 at 17:26
    
I meant bugs fixes and defects not extra features or further work –  Agush Jan 6 '11 at 3:29
    
I'm also refering to things that work in a browser, but break in another version or obscure browser. (in web development) –  Agush Jan 6 '11 at 3:43
    
Again: if your contract does not list this browser version as supported by you, it's not your responsibility. –  Mchl Jan 6 '11 at 10:55
add comment

7 Answers

up vote 38 down vote accepted

Part of your contract should describe acceptance tests i.e. tests that the client will do and your application needs to pass them for the contract to be fulfilled. Anything not covered by these tests is client's responsibility. Anything covered by them is yours.

Because it is not possible (especially for a non-technical client) to forsee all possible issues, you should add into your contact a clause specifying a period, when you will fix any new issues as part of a contract. After that, you should offer only paid support.

share|improve this answer
1  
I have a feeling it's probably too late for this particular client, but this is good advice for the future. –  Dean Harding Jan 4 '11 at 9:02
1  
Even with his current client Agush could agree on a set of acceptance tests. It's important to explain to the client, that agreeing on such tests will result in quicker delivery of a functional application. If the client is sensible, they will agree. –  Mchl Jan 4 '11 at 9:50
    
Precisely. What you're going to do needs to be stated in the contract or agreement ahead of time to everyone's satisfaction. After that its too late. Once the project is delivered if you and the customer disagree you're going to have to find a way to compromise on that and this could be tricky. –  glenatron Jan 4 '11 at 10:29
add comment

It depends.

In the first instance you should pay as it can be argued that the work isn't complete.

Later on the customer should be paying for continued support.

However, the problem is in deciding where the boundary is and what constitutes a bug and what's a new feature. Having requirements and/or acceptance tests goes a long way to defining this.

You really need to get these things in place before you deliver the work, but if you haven't then perhaps now is the time so say - "I'll support this for free for the next N days/weeks, but after that we need to discuss a support contract" (note my emphasis on "we").

Having said all that though, there are times when you will need to fix a bug for free and take the hit. If nothing else it builds up good will.

share|improve this answer
    
From where you are now, this is good advice. You may have to keep fixing bugs for this customer for a while in the interests of good will and reputation which mean a lot if you are just starting out. Consider this the price of learning the lesson about establishing what is in and out of scope for support as part of your contract... –  glenatron Jan 4 '11 at 10:31
add comment

All of the answers given above are good. However, I'd add a few bullet points to consider:

  • Is the client valuable to you? Sometimes it is worth going the extra few yards to keep a client happy if you feel they are valuable to you and will bring you more work in future. You need to find a balance between being strict and flexible and this may differ for each client. No point losing future work just because you are adamant that an easy-to-fix bug falls out of scope. On the other-hand, you don't want to let the client walk all over you. It's a delicate balance!

  • Is the bug something that could easily have been missed in user testing? For instance, take a date-related bug that only comes into play when a certain year is entered (think Millennium bug etc). A client couldn't reasonably be expected to spot this during testing therefore the onus is on you to fix it.

share|improve this answer
    
Totally right I ended up fixing them, as losing the client ain't worth the trouble, for now. –  Agush Jan 6 '11 at 3:35
add comment

When I was freelancing, my basic customer agreement defined a condition called "acceptance", which was required before I put the project live to the public. At the moment of acceptance, there began a 30-day period I called "up and running support". After that 30 day period, ongoing work on the project was billable hourly.

If you have a good relationship with this client, have a heart to heart with them about how unworkable the current situation is for you, and propose a fair hourly rate for ongoing maintenance and support. People sometimes think that buying custom software is like buying a sandwich or something, like once it's built it's done. It's just not like that.

share|improve this answer
    
Thanks this is a good way to handle it. A period of support after acceptance, and after that, they are on their own. –  Agush Jan 6 '11 at 3:39
add comment

Generally you can go for a free support for fixed number of days after you deliver the application. Certainly a life time free support is not possible/unacceptable.

Make sure the bug raised is a BUG and not a change to existing feature. For any feature change you should charge.

share|improve this answer
add comment

If he tested it and signed it off, you could argue that he should pay.

If you pride and value your work, you could argue that you would fix the code. Learn from the experiences and build better code next time, more efficiently. Or factor in more profit to cover bug-fixing.

If the program does something undesirable or unexpected given the inputs, then it's a bug, and should be fixed.

You could have quoted for the support fee up front as an extra to the initial development work.

share|improve this answer
add comment

In your contract, specify a per-hour rate and keep track of your time. When you give your client the price, specify that this is an estimate and the actual result may be less or more.

Keep the client up to date on the progress, and when he inevitably makes suggestions, you can simply tell him the time it will take you (if change is outside original specifications) and he can decide whether the change is worth the money. Therefore only changes important to him will be added.

I would personally cover acceptable vs unacceptable (paid support vs free support) bugs in the contract, and that way you at least have something in writing from the get go. He will undoubtedly wonder why you should need that clause, so be upfront and explain that if a new OS update comes out that breaks something, that isn't free support. However, bugs in your code according to the original specification on the specified platforms would be covered.

However, I should mention I have only done freelance IT work rather than programming. This could possibly scare off clients, but just make sure your work sells itself, be more professional, outgoing, and helpful than the rest, and be forthcoming with your reasons for having a more strict contract.

Besides, a client who won't accept that clause is most likely a bad client.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.