🐈 Community
amyrockwood
Member

Project closed and client requesting for me to fix something "quick"?

I wrapped up a project three weeks ago and the client closed out the project this week.  She gave me 5 stars.  Now it seems like she has gotten round to testing the app I created and she is seeing an issue she wants me to fix.  She emailed me about the issue and asked me if I could look into it and she hopes it's just a "quick fix."  It may be something I can fix in 10 minutes, or it could be something that takes longer I don't know until I look into it.  She will want to set up a call and share her screen for me to look at it.  Question:  Do I just do the quick call to see if I can fix it quickly, or do I request another contract for my time to do this?  I am not sure how long it will take, but I feel like I should be paid for my time too (especially considering my rate).  What do you usually do?  Would you do a quick look at an issue with no contract?

ACCEPTED SOLUTION
florydev
Member


Amy R wrote:

I wrapped up a project three weeks ago and the client closed out the project this week.  She gave me 5 stars.  Now it seems like she has gotten round to testing the app I created and she is seeing an issue she wants me to fix.  She emailed me about the issue and asked me if I could look into it and she hopes it's just a "quick fix."  It may be something I can fix in 10 minutes, or it could be something that takes longer I don't know until I look into it.  She will want to set up a call and share her screen for me to look at it.  Question:  Do I just do the quick call to see if I can fix it quickly, or do I request another contract for my time to do this?  I am not sure how long it will take, but I feel like I should be paid for my time too (especially considering my rate).  What do you usually do?  Would you do a quick look at an issue with no contract?


This is about managing client expectations and in the future it would be better for you if you client understood how this would work before they closed the job.

 

The problem I see with asking for another contract is if the client feels this should be included with what you originally did then what kind of rating will you expect to get?   Maybe you don't care.

 

I would probably ask them to write up the bug in as much detail as they can and then review it to see what they are seeing.  There is no reason to do a phone call, make them do the work of documenting the problem.  I am highly skeptical of anyone being able to determine how long it takes to fix a bug that didn't write the code involved so, like you, I don't buy the 10 minutes.

 

If it is actually a bug and is in the scope of the work that I actually did I would probably just do it.  Keeping the goodwill of the client is worth far more to me than a smidge of work.  But if it were an hourly job and still open I would definitely charge for that, and I would be irritated that they closed the job then tested it.  On a fixed rate job if they had found the bug before they project was closed I would have fixed it, that's the burden of a fixed rate job, so really it is just a matter of timing.

View solution in original post

20 REPLIES 20
hoyle_editing
Member

From what you have said im not sure why you would charge? if you are just looking at the problem (that im assuming the client is saying is a problem with your work?) then i dont see any reason to charge. You dont charge for reading job adverts do you?

Then, once you have seen the problem you should be able to decide if it is something you should fix because its your mistake/something you have missed from original contract (in which case you should be doing it as part of the original contract and not charging more for IMO)

OR you THEN tell the client it will be extra as its outside the scope of original work but something you are happy to deal with once a new contract/milestone has been set.

 

Just my thought.

Jon

 

But isn't that the nature of something developed?  You complete the project (which they've tested and signed off on) and then now they're finding an issue.  Even if it's my fault I would have been paid for it before when the contract was open.  Now I'm expected to work for free because it might be something I've missed - even though the client tested and signed off on the original contract?  I guess I can take a quick look at it, but it takes time out of my day.....


Amy R wrote:

But isn't that the nature of something developed?  You complete the project (which they've tested and signed off on) and then now they're finding an issue. 


Sorry, I would never DREAM of charging for fixing my mistakes.

If I buy something and it does not work, I expect the seller to fix it.

Also, the client may still be able to dispute the entire contract...

 


Amy R wrote:

 Even if it's my fault I would have been paid for it before when the contract was open


You were paid for it, so the client should have it, working correctly.

 


Amy R wrote:

Now I'm expected to work for free because it might be something I've missed -


If it was your mistake, you should fix it free of charge. I am at a loss how there could be any other answer.

If it was not your mistake, you can charge.

 


Amy R wrote:

I guess I can take a quick look at it, but it takes time out of my day.....


It takes time out of the client's day to have to deal with something not working they have paid for.

There are always little bugs to be fixed and I can't find them all....that is why the client does testing before we close out the contract.  If she didn't find a bug before we closed the contract is that my fault?  I fully tested it before I considered it closed and the issue she is having was not occurring.  Plus she may have been in there trying to fix it herself since she was learning at the time.  Are you all developers?  I would love a developer's point of view on this.  I emailed her and told her I would take a look but I also asked her if she has been in there and possibly made some changes on her own.  She has not responded.


Petra R wrote:

Amy R wrote:

But isn't that the nature of something developed?  You complete the project (which they've tested and signed off on) and then now they're finding an issue. 


Sorry, I would never DREAM of charging for fixing my mistakes.

If I buy something and it does not work, I expect the seller to fix it.

Also, the client may still be able to dispute the entire contract...




I understand the reaction but at some point a software developer is not responsible for maintaining a piece of software for eternity.  There has to be some cutoff when the client accepts that it works generally like they need it to and they are responsible for it's continued maintenance.  Out in the real world I give them 90 days and I have to say they almost never use it wisely.  

 

If this was a fixed priced contract they should have tested and found the bug in the 14 days.  If it were hourly then they shouldn't have closed the project.  It may not seem right to you but yes, I charge people hourly to fix bugs that I created.  On a fixed price project that time is factored in.

 

Bugs are just a reality in this line of work.  Many of them are really miscommunications and some of them are not bugs at all but scope changes.  Navigating that is definitely part of the trick.  So when this client says bug, it could mean, I really wanted it blue but I know I said green to I gave you the wrong formula for that field to the programmer really messed up.

 

I would probably fix them all anyway but I am really good at fixing my own bugs because I have had a lot of practice.

The project was hourly....but she is a newbie at Upwork.  I prompted her to close the contract after 3 weeks (she did not know she needed to close it at all), so I will give her a break on this one.  But I now know better how to handle closing out these contracts thank you so much for your input on this Mark!!


Mark F wrote:


I understand the reaction but at some point a software developer is not responsible for maintaining a piece of software for eternity.  There has to be some cutoff when the client accepts that it works generally like they need it to and they are responsible for it's continued maintenance.  Out in the real world I give them 90 days and I have to say they almost never use it wisely.  

 

If this was a fixed priced contract they should have tested and found the bug in the 14 days.  If it were hourly then they shouldn't have closed the project.  It may not seem right to you but yes, I charge people hourly to fix bugs that I created.  On a fixed price project that time is factored in.

 

Bugs are just a reality in this line of work.  Many of them are really miscommunications and some of them are not bugs at all but scope changes.  Navigating that is definitely part of the trick.  So when this client says bug, it could mean, I really wanted it blue but I know I said green to I gave you the wrong formula for that field to the programmer really messed up.

 

I would probably fix them all anyway but I am really good at fixing my own bugs because I have had a lot of practice.


Makes sense, Thanks for explaining.


Petra R wrote:


Makes sense, Thanks for explaining.


You are welcome and you totally rock.

florydev
Member


Amy R wrote:

I wrapped up a project three weeks ago and the client closed out the project this week.  She gave me 5 stars.  Now it seems like she has gotten round to testing the app I created and she is seeing an issue she wants me to fix.  She emailed me about the issue and asked me if I could look into it and she hopes it's just a "quick fix."  It may be something I can fix in 10 minutes, or it could be something that takes longer I don't know until I look into it.  She will want to set up a call and share her screen for me to look at it.  Question:  Do I just do the quick call to see if I can fix it quickly, or do I request another contract for my time to do this?  I am not sure how long it will take, but I feel like I should be paid for my time too (especially considering my rate).  What do you usually do?  Would you do a quick look at an issue with no contract?


This is about managing client expectations and in the future it would be better for you if you client understood how this would work before they closed the job.

 

The problem I see with asking for another contract is if the client feels this should be included with what you originally did then what kind of rating will you expect to get?   Maybe you don't care.

 

I would probably ask them to write up the bug in as much detail as they can and then review it to see what they are seeing.  There is no reason to do a phone call, make them do the work of documenting the problem.  I am highly skeptical of anyone being able to determine how long it takes to fix a bug that didn't write the code involved so, like you, I don't buy the 10 minutes.

 

If it is actually a bug and is in the scope of the work that I actually did I would probably just do it.  Keeping the goodwill of the client is worth far more to me than a smidge of work.  But if it were an hourly job and still open I would definitely charge for that, and I would be irritated that they closed the job then tested it.  On a fixed rate job if they had found the bug before they project was closed I would have fixed it, that's the burden of a fixed rate job, so really it is just a matter of timing.

Thanks Mark.  I will look into it for her quickly, but for her to say it's a "quick fix" - how would she know?  You're right, in the future I will make sure they understand that closing the contract means they have fully tested the solution and any issues after we close the contract will require another contract.  Unfortunately as a solution developer we cannot foresee all scenarios that might lead to bugs so we have to rely on the customer to do testing on their own as well as my full testing on my side.  I even hold a closing call with the client where we test everything in several scenarios before we close the contract.  This is not the first time a client has come back because they found a bug after closing the contract.  It is the nature of developing solutions.  I just have to set expectations I guess.  I mean how long after closing the contract can they come back with bugs when we've already covered/tested in previous testing before the contract was closed? Two weeks, three weeks, a month?  You never know when the client gets around to testing on their own with scenarios I could not think of.  Plus many clients get in there and try to fix it themselves and might change something inadvertently which affects the functionality of the app (and they may deny this thinking nothing they've done would affect it).  It is an interesting situation.  I do of course care about my rating as I am top rated with a 100% success rating.  I am just unsure how to handle these situations.


Amy R wrote:

Thanks Mark.  I will look into it for her quickly, but for her to say it's a "quick fix" - how would she know?

Well, first off you did say that she says she "HOPES" its a quick fix originally - implying that she is hoping it wont be much work/cost to fix?

 

This is all speculation though, until you actually look at how big the problem is (or isnt) then there is little point worrying - I see no logic in thinking about charging to look at and/or discuss a problem that may or may not be your responsibility to amend. Once you have taken a look or had discussions with the client then i guess its down to your judgement!

 

If it was on an hourly contract and bug fixing is generally a part of that hourly contract then it should be no problem for the client to open up a new contract, but if its a 10 min fix then personally i would more than likely just do it!

 

 


Jonathan H wrote:

Amy R wrote:

Thanks Mark.  I will look into it for her quickly, but for her to say it's a "quick fix" - how would she know?

Well, first off you did say that she says she "HOPES" its a quick fix originally - implying that she is hoping it wont be much work/cost to fix?

 


Yeah, I caught that too, there is a good chance that she knows it's an ask because I might expect her to say something like "when can we get this fixed?"

 


Amy R wrote:

Thanks Mark.  I will look into it for her quickly, but for her to say it's a "quick fix" - how would she know?  You're right, in the future I will make sure they understand that closing the contract means they have fully tested the solution and any issues after we close the contract will require another contract.  Unfortunately as a solution developer we cannot foresee all scenarios that might lead to bugs so we have to rely on the customer to do testing on their own as well as my full testing on my side.  I even hold a closing call with the client where we test everything in several scenarios before we close the contract.  This is not the first time a client has come back because they found a bug after closing the contract.  It is the nature of developing solutions.  I just have to set expectations I guess.  I mean how long after closing the contract can they come back with bugs when we've already covered/tested in previous testing before the contract was closed? Two weeks, three weeks, a month?  You never know when the client gets around to testing on their own with scenarios I could not think of.  Plus many clients get in there and try to fix it themselves and might change something inadvertently which affects the functionality of the app (and they may deny this thinking nothing they've done would affect it).  It is an interesting situation.  I do of course care about my rating as I am top rated with a 100% success rating.  I am just unsure how to handle these situations.


Well if the code is in source control then you should be able to see if anyone has changed it since you last committed it.  If the code is not under source control...the code should be under source control.  

 

You will see in the community it is quite common for clients to come back asking for infinite revisions across all spectrums of work.  Outside of Upwork I give 90 days and I communicate with my clients many times that hey, you have 90 days to get this tested out and fill good about it and after that we are on hourly.  About a week before the 90 is up I send my last reminder.  At the end of the 90 days I send a notice of project completion.  I swear they wait until the last day every time Smiley Happy.

 

On here, with fixed work I would after submitting tell the client they have 14 days to test it before the milestone closes on its own (that's from memory, haven't had a fixed priced contract yet).  I would use that as the grace period for finding bugs because that is what it is for.  I think it is very important in any project but in particular fixed priced projects to make sure that you clearly define what is in scope.  One of the advantages of Upwork is you can fallback on how it works and its rules, the 14 days for example.

 

Hourly, I would tell the client although I am done with the work let's keep the contract open in case their is any changes.  It sounds way better than bug fixes.

 

prestonhunter
Member

Not everything that a client identifies as a "quick fix" is actually a "quick fix."

 

Many things are not a "fix" at all... but something new or different that a client wants to implement.

 

Many things are actually "quick."

 

A client may be confused about what "quick" means in this context.

 

Maybe it only took a minute for the client to describe the issue. So for the client, describing it was "quick."


But how long will it take for the freelancer to:

- implement this new feature

[or]

- change this existing feature

[or]

- fix this bug?

 

It might indeed by "quick." It might not.

 

How long is "quick"?

 

One minute?

Ten minutes?

An hour?

 

Here are some raw facts:

a) An Upwork contract is not indentured servitude. An Upwork contract does not entitle a client to the freelancer's labor forever.

 

b) Once a contract has been closed, the client has essentially no leverage. The client no longer has the ability to give the freelancer feedback. Essentially the only thing the client can do (for a limited time) is resort to "dirty tricks" like trying to get a refund for work that the client has already signed off on as successfully completed.

 

c) A serious, professional client would never even think about asking a freelancer who was hired previously on a closed contract to come back and do work on her project, without offering to pay the freelancer. No matter what kind of "fix" and no matter how "quick."

 

d) A professional freelancer values customer satisfaction, and feels a sense of professional pride in his work. There are instances where a freelancer will legitimately refuse to accept pay for "a quick fix." But this is the freelancer's choice. Always. Most of the time, if a client asks the freelancer to come back and do more work, the freelancer should get paid. But if the freelancer feels like he really did make a mistake on something related to previous work, and that the client is not asking for new work or asking for something unreasonable, then it is completely ACCEPTABLE for a freelancer to do a quick fix without charging the client.

 

e) If a client hired a freelancer using an hourly contract, then it makes no sense whatsoever for the client to ask the freelancer to do any additional work for free. The client paid the freelancer for his time, not for a specific deliverable. If the client wants more of the freelancer's time, she needs to pay for that time.

In my experience, when a client says it's a "quick fix," they are hoping it will be free. I would never work on a project again without a contract. That contract offers you all sorts of protection especially if that "fix" isn't so "quick." 

So I just hung up with the client....it was not a quick fix and nothing I could have foreseen.  BUT I did fix it for her.  THEN she showed me something she changed on her own without knowing the ramifications which broke the app as well.  So I fixed that too.  Total I spent an hour on the call and fixing these issues and fully testing with her.  At the end of the call I confirmed she feels everything is working as expected, and explained that she could test for the rest of the day and if she came across any "bug" she could contact me and I would fix anything else with a new contract.  I offered a reduced rate to further troubleshoot any issues with existing functionality (there shouldn't be much at this point we've tested the heck out of this thing).  I also explained new functionality (such as what she tried to implement on her own), would require a new contract at my full rate.  She was very happy and totally agreed and understood.  Mark thank you so much for your help and direction on this.  I'm glad I maintained my professionalism and did not upset my client.  I'm also happy to know our future engagements are now agreed upon.  Thanks everyone!!


Amy R wrote:

So I just hung up with the client....it was not a quick fix and nothing I could have foreseen.  BUT I did fix it for her.  THEN she showed me something she changed on her own without knowing the ramifications which broke the app as well.  So I fixed that too.  Total I spent an hour on the call and fixing these issues and fully testing with her.  At the end of the call I confirmed she feels everything is working as expected, and explained that she could test for the rest of the day and if she came across any "bug" she could contact me and I would fix anything else with a new contract.  I offered a reduced rate to further troubleshoot any issues with existing functionality (there shouldn't be much at this point we've tested the heck out of this thing).  I also explained new functionality (such as what she tried to implement on her own), would require a new contract at my full rate.  She was very happy and totally agreed and understood.  Mark thank you so much for your help and direction on this.  I'm glad I maintained my professionalism and did not upset my client.  I'm also happy to know our future engagements are now agreed upon.  Thanks everyone!!


You are very welcome, glad to have helped!


 


Amy R wrote:

So I just hung up with the client....it was not a quick fix and nothing I could have foreseen.  BUT I did fix it for her.  THEN she showed me something she changed on her own without knowing the ramifications which broke the app as well.  So I fixed that too.  Total I spent an hour on the call and fixing these issues and fully testing with her.  At the end of the call I confirmed she feels everything is working as expected, and explained that she could test for the rest of the day and if she came across any "bug" she could contact me and I would fix anything else with a new contract.  I offered a reduced rate to further troubleshoot any issues with existing functionality (there shouldn't be much at this point we've tested the heck out of this thing).  I also explained new functionality (such as what she tried to implement on her own), would require a new contract at my full rate.  She was very happy and totally agreed and understood. 


That is just awesome!

 

Preston H wrote:

 

b) Once a contract has been closed, the client has essentially no leverage.


This is completely untrue, and what is worse: You know perfectly well that it is not true.

Why do you keep posting advice you must surely know to be entirely untrue and inaccurate, and which surely you must know that trusting that poor and false advice can seriously harm the freelancer in question?

It looks like you are on some mission to do as much harm as possible to as many freelancers as you possibly can.

 

 


Petra R wrote:

This is completely untrue, and what is worse: You know perfectly well that it is not true.

Why do you keep posting advice you must surely know to be entirely untrue and inaccurate, and which surely you must know that trusting that poor and false advice can seriously harm the freelancer in question?

It looks like you are on some mission to do as much harm as possible to as many freelancers as you possibly can.

 


I want to make sure I understand why it is not true, can you explain?


Mark F wrote:

Petra R wrote:

This is completely untrue, and what is worse: You know perfectly well that it is not true.

Why do you keep posting advice you must surely know to be entirely untrue and inaccurate, and which surely you must know that trusting that poor and false advice can seriously harm the freelancer in question?

It looks like you are on some mission to do as much harm as possible to as many freelancers as you possibly can.

 


I want to make sure I understand why it is not true, can you explain?


I suspect, if I have been paying close enough attention in guru school, that it is because the client can request a refund or file a dispute for 30 days after the contract closes...