We launched our support plans at about the time we finished developing phase one of this web application. This client opted for a support plan that allowed us to not only maintain their codebase and fix any bugs that popped up, but also add some improvements to the existing functionality.
In addition, they opted for weekly error monitoring which allowed us to catch issues quickly and fix them even before the users reported them. There were several instances where we saw an error, found the fix, and implemented the fix all before anyone (maybe even the end user) knew there was a problem.
This client also opted for a support plan that included a security audit. Given that we push clients to control all their own accounts (like hosting, codebase, etc.), the security audit gives us a good chance to review everything and make sure to close any loopholes that may have been left open by developers or the client. In this case, we did recommend that the client turn on two-factor authentication on the server account to make it very hard for unauthorized access. We also found a couple logs that indicated possible vulnerabilities. They didn’t end up being security issues, but if they were, the support plan would have saved the day.
As part of the support plan, the client was able to reach out and get immediate help when a couple issues affected their customers. We answered several emails and got issues fixed right away.
Now that the application has hundreds of people using it every day, small bugs started popping up. It was nice to have a budget to get those fixed quickly. Some bugs were related to unconventional usage and others were just difficult to test for. But it was nice for the users to log in and magically find things working as expected.
In addition to bug fixes, we were able to increase the page speed of several pages. This type of work isn’t typically included in a support plan, but sometimes we’ll make a judgement call to make improvements if the budget allows and if we think users will benefit from it.
