In a perfect world, every application would sit comfortably atop wholly stable, never-changing systems.
Unfortunately for utopians everywhere, however, the foundation upon which modern software is built is much more akin to a ticking time bomb.
While software solutions should always be delivered in working order, all it takes is a single Windows or Linux update failing to play well with a program for something somewhere to snap.
And just to make matters worse, these things are completely unavoidable!
But they also beg the inevitable, oft-awkward question: when so-called bugs eventually do make an appearance, who should be responsible for paying for them?
Breaking Bugs Down
Naturally, every software company will be inclined to deal with things in their own manner, so it is always advisable to familiarise yourself with these sorts of procedures, no matter the service provider.
For our part, however, we lean towards dividing suspected errors into a few broad categories and acting on a case-by-case basis. The following examples should help to illustrate this point:
1. Errors of our own doing
While we do our very best to ensure the utmost quality of our software solutions, it should come as no surprise that no application can ever be completely immune to human error. For this reason, after adequately surveying a reported problem, if the error is deemed to have been caused by one of our development teams, then we are certainly prepared to handle the issue with our own available resources.
Nonetheless, if an error appears during active support or development, then we will simply treat it as a new requirement and add it to the scope of your project. This allows us to prioritise fixing the error just as we would do any other task in development. So while our own development team follows strict procedures to avoid making these mistakes, in practice, whenever they do take place in development, it is up to customers to cover the costs.
2. Feature “bugs”
The next group of defects is always the result of some form of miscommunication. Of course, we ardently encourage all our customers to become fully engaged in the development process, but when this advice is neglected, misunderstandings are bound to occur. As a result, unwanted or marginally incorrect features get developed, and the common knee-jerk reaction is to immediately label them “bugs.”
Be that as it may, significant time goes into developing each element in a software solution, which means that while some features may occasionally turn out to be undesired, rectifying this error must be covered by our customers in the end. This task will always be treated as a new requirement.
3. Bad updates
These are likely the most common types of purported bugs, and can easily be spotted when out of the blue, a previously flawless feature will mysteriously stop working. As mentioned above, this is usually the result of a third-party software update.
In these cases, although it is always preferable to have in-house teams in place that are qualified to provide this level of support, we make ourselves available for any assistance that may be required. This could be as simple as contacting your patch providers for a quick workaround solution or as complex as dealing with a full API change. Nonetheless, because these issues are simply inherent to any piece of software, we are afraid we cannot be held responsible for them.
A Neutral Third Party
In order to avoid disputes and minimise risks, we recommend implementing software with the help and guidance of a fully neutral quality assurance team.
This allows customers to be given an accurate assessment of the final state of a product upon delivery, and ensures that everything is running as smoothly as intended.
So Really, Who Should Pay?
If you’re still not quite sure you understand, then not to worry! Take a look at the helpful chart we prepared for you below:
In summary, however, every case is unique, so determining who should be responsible for paying for bug fixes is a matter to be thrashed out in a contract. Never assume that software companies will take care of any issues arising after deployment.
Instead, patiently discuss the matter with your software providers and trust that they too want to help you achieve the best possible outcome.
