How prompt should we fix bugs after app release?

Question

So I made an app, we tested it and the app is published to public. The client returns to me in 10-15 days saying that users reported more bugs. I usually give 1 to 3 months of free after-release support which states that I will fix bugs for free.

Now I have some questions.

1. Since I have multiple project in working and in queue, should I fix those bugs immediately if the support period has not expired or I should tell the client that I will fix it as soon as I have free time? What I am asking is does free support mean that I have to fix bugs immediately or simply free but in my free time?
   As you see I am confused with "support" and "retainer" terms. Since I see support as whether I will charge the client or not, while retainer means to me immediate action on any issues.

2. What is the optimum free support in terms of duration? Is 1 month too short or is 3-month period too long? Should we offer free support at all since we're freelancers, not companies?

I am basically asking how do you handle such situations. Since right now the client hired me 40 hours a week and it's not fair I cut from 8-hour day work by doing bug fixes. And yet again, fixing those bugs at night is error prone since I am tired.

Answer 1

In a project I recently finished, we offered a warranty period for 60 days after the release date, in which we agreed to fix all critical and high priority defects within 48 hours. You could offer something similar. The key is to get mutual agreement on what is critical/high priority.

• Is this just copy changes? Could be low, could be high depending on the nature of the copy
• Is this because the user expected a feature to work in a different way? That's a change request
• Is this actually an area of functionality that is broken?

You probably need to think about the kind of issues that are being found on your projects currently and decide on what you believe is a critical/high priority issue. That should give you some guidance that you can give to clients regarding the kind of issues that would fall under critical/high priority. That's the only grey area in this really. If you don't provide boundaries for priority there is a chance that a client could try to push all defects through as critical. Each needs to be evaluated separately but you should agree the priority before tackling each one.

If a reported defect is not critical/high priority, you could still agree to fix those within X days (7 for example). Once the warranty period elapses, any further reported defects should be chargeable. I think it's entirely reasonable to expect the client to pay for your time to fix defects if they don't find them for 2 months after you complete work on their software. As long as you are up front about that and the warranty period and defect resolution agreements are written into your contract then you should be covered for the point at which you can start charging for fixes. The only issue that might arise is if a defect takes longer than 48 hours to fix. You probably want to include a clause in the contract allowing for this.

You could even state that you will fix critical/high bugs within 48 hours in the first 30 days and within 7 days in the second 30 days (or something like that), which should encourage the client to fully test the app post-release and report issues promptly so that you can deal with them and hopefully put the project to bed without it rumbling on and disrupting other projects that you may also be working on.

Answer 2

Since I have multiple project in working and in queue, should I fix those bugs immediately if the support period has not expired or I should tell the client that I will fix it as soon as I have free time? What I am asking is does free support mean that I have to fix bugs immediately or simply free but in my free time? As you see I am confused with "support" and "retainer" terms. Since I see support as whether I will charge the client or not, while retainer means to me immediate action on any issues.

What you could do temporarily, if your time allows for it, is to set aside one or two hours a day for bug fixes. Free bug fixes can be on your own schedule provided the contract doesn't specify a time limit on post-acceptance bug fixes.

That being said, you may want to specify in your future contracts that post-acceptance bug fixes will be prioritized (on a scale of wrong-shade-of-turquoise to does-not-work-in-IE10) and fixed in a reasonable amount of time for the bug's severity.

What is the optimum free support in terms of duration? Is 1 month too short or is 3-month period too long? Should we offer free support at all since we're freelancers, not companies?

It depends on what "free support" means. After the client has signed off on it, that means that they've accepted the current state of code as being complete. At most, I would offer a discounted rate for 30 days after acceptance for major issues, but I would not offer free support. That attaches more value to the acceptance testing, which helps your overall timeline and reduces surprise time commitments.

To bounce back to your other question, being on retainer implies that the client has paid you an amount of money to remain available to them. If they have paid this, then you may treat bug fixes at the same priority level as current work projects.

Answer 3

Going along with what @ChrisForrence said, set aside some time each day to deal with bugfixes for previous clients. If you are still in a "support period" with them, and I assume they paid you already, then you owe it to them.

That said, I would limit the priority to these areas (in order of priority):

• Critical Failure, the app does not function as you said it would and cannot be used properly until fixed.
• Level 3 (or whatever), the app still functions but there is a feature that is failing and it's readily apparant to the end user. The problem is seen by 75%+ of users.
• Level 2, Same as L1 but is seen by more users, generally 41% to 75%.
• Level 1, the app functions just fine but a feature is not functioning correctly. Less than 40% of the users affected.
• Level 0, the bug was only noticed by an edge case. E.g. the users was wearing an aluminum hat, had their feet in a bucket of ice water, and they were in a centrifuge used to test human endurance for space missions and said centrifuge was operating at 100%. Congratulate them for even being able to attempt to use your app under these conditions before explaining that you'll get to it if you can find the time.

(Just to be up front about my method, I completely made up these numbers once. They have no basis on any research, they were just gut feeling numbers.)