Client suspended dev work, but still wants fixes

Question

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.

Answer 1

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)

Answer 2

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).

Answer 3

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.

Answer 4

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?

Answer 5

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".

Answer 6

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.

Answer 7

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.