A Non-Technical Client And Bugs

・4 min read
A Non-Technical Client And Bugs

In this article, I would like to suggest a few techniques which can help you handle errors in production if your client is non-technical. The best way to handle errors is, of course, to prevent them from occurring. We can try to achieve that by writing reliable test suite, code reviews, and QA. But this is not the topic of this article. Instead, I will focus on the situation where all of those good practices were not enough and something bad happened.

Finding bugs

An excellent idea that you can implement in your project is adding an error tracking system to your application (for instance, Honeybadger or Airbrake). Service like this notifies you immediately after something wrong happened in your application. It allows you to act faster as opposed to waiting for the client’s bug report. An error tracking system provides you with a stack trace, together with the details about the request and environment that triggered the error. Usually, it is everything you need in order to quickly debug your problem.

Unfortunately, not every type of errors can be found that way. A feature that “works” but was not implemented according to the client specification is one example. This type of errors is usually reported by the client. In an ideal world, bugs like this should never left the staging environment but unfortunately, it sometimes happens. This brings us to the next point:

Reporting bugs

In order to save your time (and the client’s money), it is wise to educate your client how the errors should be reported. I suggest to ask your client to always provide you with those three things:

  • a screenshot
  • an URL where the error occurred
  • a description of what happened or what should have happened but didn’t

That information should go directly to your ticketing system (for instance, Trello, Pivotal Tracker, Jira) and be reported as a bug. A good practice is to send a link to the ticket on a dedicated channel on a collaboration hub (for example Slack or HipChat).

Another thing that has to be explained to the client is the urgency of an error. Most errors should be fixed as fast as possible, but some bugs like, for example, a typo in the description can wait till the next morning. On the other hand, showstoppers as a cart price being wrongly calculated should be fixed immediately.

Handling bugs

As I mentioned before, all bugs should go directly to your ticketing system and therefore, they should be treated as regular tasks. What it means is that each error:

  • should be prioritized
  • has to be assigned to someone
  • has to be resolved (obviously) with adding a regression test
  • has to be reviewed
  • QAed
  • has to be deployed

Of course, if a quick fix is needed you can speed this process up but after the bug is fixed, it is wise to go back and do everything the right way.

As a team leader, you should also take care of the client. You should explain what happened and why. Estimate the possibility of a new occurrence, and suggest the way of fixing the bug. You should also provide the client with a time box in which the fix will be ready on production.


You should always apply best practices in your projects to avoid bad situations. But if some errors slip through your test suite, code reviews, QA and testing on staging, be sure that you handle it in a proper way. Remember, that it is your duty to help your client and to educate him about the processes and best practices. Your effort will pay off in the long run.