Three things in life are certain; death, taxes and bugs.
When creating an LMS, membership site or any other software product, it’s inevitable that bugs will come up. And it’s also quite common for clients to question who should pay to fix them.
When you decide to build your own piece of software, you are not buying a finished off-the-shelf product; rather you are paying for the iterative/explorative process of developing your own.
If you opt for the off-the-shelf approach and host your content on platforms like Kajabi, Teachable or Squarespace, then you pay a monthly subscription or license fee to rent the use of their software. If you find a bug, since it’s their software, it’s ultimately their responsibility to fix it. It’s a very risk-free approach, but as you know, off-the-shelf software is often very restrictive, so building your own can be an attractive approach.
However when you build your own software, while you free yourself from the limitations that come with off-the-shelf solutions, you’re also taking on a certain amount of risk.
An agency like Plume can help to mitigate these risks, but it isn’t up to the agency to financially own them.
Bugs are one of many risks that you will need to consider, and it’s ultimately your responsibility to fix them.
First, it’s important to understand the definition of a bug:
A software bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
Wikipedia
When a developer works to build software, the dev is, by definition, bug-fixing from the very first line of code. No developer writes perfect code from the start, so it undergoes constant bug-fixing to get the code into a usable position. Even when it looks stable, the developer will still actively try to break the software, in order to find more bugs to fix.
The developer could spend hundreds of hours testing for and fixing bugs. But since we charge by the hour, those hundreds of hours would ultimately be billed to you. That isn’t very agile, nor is it cost-effective for you, so we have to strike a balance between writing bug-free code and cost/value.
As a way to reduce your costs, we also ask you to help test our work, to ensure that it’s up to the standards that you expect.
With this in mind, sometimes bugs make their way into the live site and are discovered by you or your users. You may feel that this bug shouldn’t exist and that you shouldn’t need to pay for it, but as we just learned, bug-fixing is development. The fact that the bug was uncovered by you after the initial release, rather than a developer or QA engineer, doesn’t make the bug-fixing work any less valid or valuable.
Either way, whether we find the bug and fix it, or you find the bug and we fix it, the time it takes to write code is billed and an expected part of the process. All we can do on these occasions is act swiftly and fix the bug as quickly as possible.
What if budget runs out and more bugs are discovered? We dedicate an entire week to UAT in the initial development process, which has been accounted for in the budget. This means that bugs and issues reported during UAT are typically accounted for. Bugs discovered at a later date will eat into your support plan, so it's beneficial to carry out as much UAT as you can during the implementation phase.
It’s also important to understand the infrastructure of the technology that powers your system.
Rather than build every system from the ground up, many of ours are built upon open-source content management systems like WordPress and Drupal. And the implementation of other tech is often used to extend the functionality. This allows you to build systems with incredible amounts of functionality at a relatively low cost, in comparison to building from scratch.
However, your CMS is built and maintained by one organisation, and each plugin or module on your site is likely built and maintained by a number of other organisations. That means, if you have 20 plugins on your site, there are 21 different organisations contributing to its code.
The CMS and all of these plugins get updates, sometimes as frequently as monthly. These updates improve security, stability and often add new features. When they update, the code changes. And when the code changes, there’s no guarantee that it’ll perform in the same way. Bugs may be introduced, or two plugins/modules which worked harmoniously may now conflict with one another, causing more bugs.
Then you have browsers and operating systems. They update too, and when they change, there’s no guarantee that your site will work in the same way on those devices.
Who’s fault are these bugs? They’re often not yours, of course. But they’re often not ours, either. And you can’t conclusively say that they’re the plugin author’s fault because they didn’t build the plugin with your specific site and unique combinations of plugins in mind. This is the nature of modern software development.
Therefore, although it’s nobody’s fault, the responsibility of maintaining the site falls upon you. In these instances, you will need to decide whether you can live with the bug, or if you’d like it fixed. And if you decide the latter, you need to determine whether you’d like professional help to do so. If you decide that you do, we’re happy to help resolve it.
Are bugs frustrating? Yes, incredibly so. However, this is the reality of owning your own software product. And as with any organisation with their own software, you will need to budget for these forms of operating expenses.
