I have a long term development client that recently needed to suspend development due to some financial issues on his side. Up until now for most of this year I've been on an hourly time commitment at a set rate and not on a project rate. He notified me ahead of time that starting this month, hopefully temporarily, dev work would be put on hold, and I understood and agreed.

Now, not 4 days after that he already had a request for me to fix something targeted for one of his clients. This goes along with ongoing site maintenance, and isn't new work. Ongoing site maintenance was probably 30% of the work I've done previously and been paid for hourly.

He seemed to indicate that since it was a "bug", it should be fixed even though we were not on a payment agreement anymore. The feature in question was built perhaps 6 months ago, and was only recently discovered in this client situation.

Is it appropriate to let him know I can't be fixing bugs when our agreement is suspended? Is there a way to express this without alienating him as a client, since our work may resume as soon as next month? I've let him know already that small emergency situations can be handled, but situations like this were one user finds a bug do not qualify as emergency, despite it being a client-facing issue. And it will just need to sit until work resumes.

  • 1
    "He seemed to indicate that since it was a "bug", it should be fixed even though we were not on a payment agreement anymore." You should tell him that this isn't true. Otoh, helping someone get through a rough period and aknowledgin that can yield a lot of future work, so I'd give him a free month.
    – Pieter B
    Commented May 20, 2014 at 8:10
  • You didn't answer me on: "You need to decide if client's financial woes are temporary, or if the client is going down the plughole (bankruptcy/repossession/liens/lawsuits). Did the client pay your last invoices?"
    – smci
    Commented Jun 21, 2014 at 5:09
  • The client's financial woe's are indefinite, but temporary, and no he has not paid has final invoice yet. I've suspended work, and been polite with the reminders giving him some slack for the moment.
    – Miro
    Commented Jun 22, 2014 at 11:14
  • Ask him for something else in return. For example,agree to fix the bug, but ask for a written agreement about future work in response.
    – osa
    Commented Jan 27, 2015 at 6:05

7 Answers 7


An exception or two can be made.
When you do so (fix bugs for free, outside your economic/contractual agreement) don't forget to remember to your client that what you do is a favor/exception because you know it is only a one time request and because you appreciate him/her as a respectful/respectable client.

Imagine that at his/her turn was (maybe) in the same situation when his/her client asked for the bug to be fixed.

I understand your need to get mad and feel frustrated when it comes to money but in the same time, please remember that a small favor made today can bring you more money tomorrow; this because, at the end of the day your client will appreciate you supporting his business even during difficult economic times.
Of course, your role is to make sure his/hers request is genuine and not an attempt to make you work for free or a lower hourly rate. If this is the case, than you know better what you should do (maybe terminate the contract between you two or something else that best fits your expectations or business strategy)

  • 4
    Good answer, and it's also worth emphasizing and making it clear that even "bugs" don't equate to free work. All software has bugs.
    – jmort253
    Commented May 19, 2014 at 19:35
  • Cannot add more to this. Just make sure you can really handle this free work and make sure your clients knows it's a favor.
    – Peter MV
    Commented May 19, 2014 at 19:43
  • This is a good answer. However, the question still remains for when another bug comes along in another 1-2 weeks, indefinitely. Each bug generally means about 2 hours work to debug+fix.
    – Miro
    Commented May 19, 2014 at 23:18
  • @Miro - That's why I was emphasizing the importance of saying "Hey! I'll fix this bug for you because we've been through a lot and I really appreciate your business, but I want you to know it isn't a normal thing for me to fix bugs for free. So if you have more work for me in the form of bugs/adjustments/tweaks, we'll need to negotiate a price."
    – jmort253
    Commented May 20, 2014 at 3:15
  • i guess it depends on how serious the bug is, how related the bug is to the work you got paid for, but if it's easy i'd do it. But if not then i'd explain how it's not. Commented May 20, 2014 at 6:12

You don't get free maintenance on a vehicle (unless you've paid for it, which means it really isn't free) or it's under warranty.

Likewise, unless you handed over your code and specifically mentioned a warranty in your contract (which can be oral), then it was delivered AS-IS, and the client needs to pay. Most markedly, the client also needs to understand that QA doesn't come for free (which seems to be the missing element).


As a general rule, it seems reasonable to me that you NOT do maintenance work for free after they have suspended your development contract and pay.

However, there might be a few exceptions:

  1. If it is written in your (now suspended) contract that a certain amount of maintenance/bug fixes will be done at no charge.
  2. If you feel that providing one or two bug fixes would be good PR and possibly result in the reinstatement of your contract, or a referral to other business in the future.

This also all boils down to what constitutes a "bug". You indicated that in the past, 30% of your time was doing bug fixes/maintenance. However, this was at an hourly rate, not part of a fixed project bid. So it seems logical that future "bug fixes" and maintenance would also be at an hourly rate, not a free rate.

It sounds to me like you have the high ground here, and can require them to pay your hourly rate to continue doing work. So far there is no precedence of you doing work for free.

In any case, if you decide not to do the work, I would certainly be very cordial and polite with any correspondence to the employer.


Ok I see several things in your situation:

  1. Client appears to be in financial trouble, but is trying to get you to work for free, to bridge them with their customer. You need to decide if client's woes are temporary, or if the client is going down the plughole. (Did the client pay your last invoices?) Do some discreet investigating. If you have other clients offering paid work, use that as a bargaining lever why you should not work on the current thing, unless he pays you some modest amount. I wouldn't accept deferred compensation or loosen credit terms.

1b. you seem to have gotten yourself into a bad situation where you are heavily dependent on this client (why?). Maybe it's better to spend (most/all of) your time rustling up other customers. At least it gives you leverage to require them to pay you something.

  1. Validation, bugtesting, QA, should all be scoped as a separate acceptance phase of the contract (for which you get paid, like any other work - you can schedule that that phase covers n weeks, and beyond that, any incremental work is billed hourly). This should all be clearly spelled out in the contract and project schedule: who does testing, their deliverables to you (e.g. their buglist from validation).

  2. The point is that the acceptance phase has a sharp cutoff, they pay while the clock is running in acceptance phase, and anything discovered after that cutoff is not a bug, it's a change request/maintenance. Do not accept the client's characterization of things as bugs, as that may weaken your stance if they subsequently try to stiff paying you by alleging crap like breach of contract and non-performance. (It doesn't matter here since this guy is apparently headed for credit troubles/bankruptcy not civil court, but generally don't do it.)

  3. Maintenance is also separate work, for which, as you point out, you deserve to get paid. Define maintenance contractually as any bug/issue/spec change/enhance they/you didn't catch in acceptance. Define that maintenance constitutes paid work.

So this boils down to:

a) The cleanest and most mutually satisfactory way is to spell all this stuff upfront in the contract and schedule: including acceptance phase, acceptance criteria, billing during acceptance phase, how to resolve disputes over acceptance, that you continue to get paid if they want to dispute acceptance; their obligation to send you a complete buglist by the end of their validation. Prevention waaay better than cure.

b) If you really want to keep the customer, and they're not bouncing checks all over town and getting foreclosed on, then you can make sure to communicate in writing that this is an exceptional one-off customer-loyalty situation, at your sole discretion issue them an invoice for (say) "13 x $60 hours maintenance, with a 100% customer loyalty discount", so that the invoice zeros out. But if they think they can now randomly phone you weekly for free maintenance, you're going to go nuts. In that case, invoice them and be prepared to walk. I wouldn't extend the invoicing terms to net-90. But you might give them a discount at your discretion. It comes down to: how badly do you need them, and are you prepared to walk? Do you expect them to ever pay you? Why not just suspend further work until they pay you?


Ongoing site maintenance was probably 30% of the work I've done previously and been paid for hourly.

Your prior agreement included maintenance as paid work. Now he wants to change that and you to work for free - inappropriate. You can be Mr. Nice Guy, as a couple of posters have suggested, to help them through a rough time, but yeah, tell them your aren't starting a new policy, & document it (invoice with discount). Otherwise (and maybe anyway!) you'll be spending a lot of time on free maintenance or sour your relationship when you finally say "no more".


This is actually an opportunity. I know, it sounds a bit crazy but it isn't.

Without the request to fix the bug:

It is unfortunate, but at this point and for all intents-and-purposes, your relationship with the client is over. In my experience, there is no recovery from "I can't pay you" - even when it is predictable and notice is given.

There is so much wrapped up in the client's judgement of de-prioritizing your work - or maybe he is flat broke. Either way, if you come back to the client when he is ready to start up the project again, he will know that at any time he can put you on hold again.

With the request to fix the bug:

This is the opportunity to re-establish your priority. It isn't pleasant to say, but a client must fear losing you in order for the relationship to continue. So with this request, you can answer that you will fix this bug for free while also letting him know that his project is now low-priority and that any more work will have to wait until you have the capacity.

The client may balk at this, but he'd be gone anyways.


IMO, you should support your code (bug-fixes are always free). Although you were "on a time commitment" but are no longer, has no bearing on your reputation as a developer -- you should support your code. Code changes are not the same as bug-fixes. You should be paid for changes, enhancements, site maintenance, and so on but you should stand behind the code you write.

This is assuming you are a 1099 or otherwise independent contractor, not an employee.

Supporting your code gives the client peace of mind in using you (instead of your competitor) in the first place. It also gives you a solid rep as a reliable developer, and usually opens many more doors for future work either for this client or referrals.

  • Can you define what it means to be 1099?
    – Canadian Luke
    Commented Jun 17, 2014 at 15:20
  • 2
    What the client interprets as a "bug" is often more of a maintenance item. Especially when a "bug" for him is anything that doesn't work as currently expected, whether it was designed that way, implemented that way, or because unexpected data comes to the system. The last being important, in that it works great in all expected cases when it was created, until something unexpected arrives outside the original scope later in time.
    – Miro
    Commented Jun 17, 2014 at 15:35
  • 1
    @Canadian - 1099 Applies in US, although I imagine other countries have similar. From [Wiki] (en.wikipedia.org/wiki/Form_1099#1099_series) : "Form 1099 series is used to report various types of income other than wages, salaries, and tips (for which Form W-2 is used instead). Examples of reportable transactions are amounts paid to a non-corporate independent contractor for services (in IRS terminology, such payments are nonemployee compensation). The ubiquity of the form has also led to use of the phrase "1099" to refer to the independent contractors themselves".
    – GDD
    Commented Jun 17, 2014 at 15:38
  • 2
    "(bug-fixes are always free)" I disagree completely. If the client is paying to have a development process that identifies bugs (defects) based on written requirements, which in turn requires the client paying for real analysis, then the contract will apply penalties for too many defects. But the work is always paid for. Defects are part of writing software. Choosing which defects to fix based on cost is part of it too. If the client is too cheap to pay for analysis and requirements, then a never-expiring promise to fix "bugs" is like brake pads with a guarantee on the box - i.e. "worthless". Commented Jan 26, 2015 at 23:18
  • 1
    @KeithPayne - OMG no, not during development or ALPHA or BETA testing; then it's part of development process and we are paid for it. I meant a serious bug discovered after general release - it may affect less than 1% of users in a less often used routine but to those few users, 2+2=5 is a serious bug and we fix for free.
    – GDD
    Commented Jan 28, 2015 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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