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?

  • 5
    For the serious bugs, there is usually 'hell to pay', so I guess hell pays for them.
    – user131
    Commented Jan 4, 2011 at 13:16
  • What do you mean by "bug etc."? There's a difference between bugs and further work not involving bugs. Commented Jan 4, 2011 at 17:26
  • I meant bugs fixes and defects not extra features or further work
    – Agush
    Commented Jan 6, 2011 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
    Commented Jan 6, 2011 at 3:43
  • Again: if your contract does not list this browser version as supported by you, it's not your responsibility.
    – Mchl
    Commented Jan 6, 2011 at 10:55

7 Answers 7


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.

  • 3
    I have a feeling it's probably too late for this particular client, but this is good advice for the future. Commented Jan 4, 2011 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
    Commented Jan 4, 2011 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
    Commented Jan 4, 2011 at 10:29

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.

  • 1
    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
    Commented Jan 4, 2011 at 10:31

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.

  • Totally right I ended up fixing them, as losing the client ain't worth the trouble, for now.
    – Agush
    Commented Jan 6, 2011 at 3:35

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.

  • Thanks this is a good way to handle it. A period of support after acceptance, and after that, they are on their own.
    – Agush
    Commented Jan 6, 2011 at 3:39

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.


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.


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.

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