Should You Have To Pay For Bug Fixes On Your Website?

The topic of who is financially responsible for fixing bugs on a software project is a question that often comes up during the lifespan of a website. Especially if you don’t have an extensive background in website development and support arrangements, it can be hard to determine what’s “normal” and reasonable in this type of situation.

Here’s a real life example of a question I recently received from a friend and colleague:

My org launched a “new” Drupal website last year. The agency who built the site is also managing the updates/security for the site. We have about XX hours/month budgeted for maintenance and upgrades as needed.

Over the past few months, a couple of the updates to the site led to things breaking on the website. I noticed this maybe a week or two after the update and requested the agency look into it and fix. Aside from it taking them about a month to actually fix – I was surprised that we’re having to pay for this work.

This leads me to the issue in question. The above example is one of about five that have come up over the past few months. We’re paying for them to fix these “bugs” or “breaks” – and I’m not sure if that’s standard. I didn’t request the work – only that they fix what broke.

I totally respect that the agency needs to be paid for their work – but if our entire budget is being spent on fixing problems…doesn’t feel right.

Any thoughts on this? Does this sound normal?

This is a great question, and the answer is nuanced. But to give the essential answer up front:

1. Yes, paying for bug fixes is a normal arrangement; and
2. Just because paying for bug fixes is normal doesn’t mean the amount of bugs you’re experiencing is normal or healthy.

Let me preface by saying that good client/agency relationships are built on mutual trust and open communication. If you are questioning your agency’s work, the best course of action is to come to the table with them to openly discuss your concerns and how to make things better. They may have additional context for you, including ideas for how you might be able to work with them to reduce the number and frequency of bugs.

But let’s back up a bit and talk about how and why agencies typically bill for bug fixes across the board, and the arrangements that may be the exception to that rule. Then, we can tackle the number and frequency of bugs, and what could be happening.

Let’s start with a basic fact of life:

Bugs are going to happen—and responsibility is not always as clear-cut as it seems

On a fundamental level, all software is going to have bugs from time to time, and it’s unhealthy to adopt the belief that all bugs can be avoided. While the question here is mainly about who’s responsible for paying for them, it’s worth repeating in order to set the stage.

It can be easy to think that a bug = a mistake made by the agency. And that can definitely be true. But other times, defects aren’t always so clear-cut:

• What about when something doesn’t work like it’s supposed to because of a miscommunication?
• What happens when a third-party provider makes unannounced changes that cause the website to malfunction?
• What if a staff member breaks something because they didn’t understand how to use a particular feature on the site?

In these cases, the ownership of bugs and breaks become murky and subject to interpretation. In their article Should Customers Pay for Bugfixes?, MadeTech makes the following observation:

When naming something a “bug” means that it’s free, the customer has a vested interest in naming as many things as possible “bugs”, even if the “bug” is simply functionality that was glossed over, implied, or taken for granted in planning. These conversations take a long time to have, and they are rarely productive for either party.

Now, not every client is going to adopt this kind of behavior, but agencies need to account for the possibility that this could happen and recognize that’s it’s not very productive in the context of helping their clients achieve their most important outcomes.

So, my main point is this: fixing bugs is a part of maintaining any website, and when bugs happen, it’s not always going to be straightforward or productive to assign fault.

This context is important to keep in mind as we move to discussing the ins and outs of how bug fixes are handled in a client/agency support relationship.

But what about when the bug is definitely the agency’s fault?

I imagine some readers are thinking:

But wait a minute—sometimes a bug or break is definitely the agency’s fault. Shouldn’t they be financially accountable for their work when it’s clearly their mistake?

The answer: it depends on your relationship and how it’s been structured.

• Most upgrade-and-maintenance contracts as based on a certain number of hours per month—this is time-and-materials billing.
• Typical time-and-materials billing transfers the financial risk to the client in exchange for paying a reduced cost if things are completed in less time than expected.
• It also brings more flexibility to when and how budget is allocated.

For example, say an agency estimates a 10-hour upgrade at $150/hour (for those of you who hate math, that’s $1,500). You agree to it, and it takes them 8 hours to complete.

In an hourly relationship, you pay $1,200, even if you were originally willing to pay $1,500. And conversely, if it takes 12 hours, you pay $1,800.

This is the risk/reward at play in the hourly billing model. The agency is guaranteed they’ll be paid for 100% of their time (including fixing bugs), even if it means they make less money than you were originally willing to pay.

The true cost of free bug fixes

It’s worth mentioning there a number of other billing models than can include free bug fixes. But to be totally honest, you will always be paying for bug fixes, it just depends on whether or not you want to accept the financial responsibility for them.

Agencies with arrangements that include free bug fixes (or really, any other complimentary services, such as free estimates, reports, project management, etc) must pad their fees to account for them.

For example, with free bug fixes, that estimated $1,500 upgrade would probably get padded by 20-50% (depending on the level of uncertainty around the work) and presented to you at a fixed cost of anywhere from $1,800 – $3,000. And if that padding goes unused, it goes straight to the agency’s bottom line instead of back into your pocket.

Some clients will prefer one or the other, and it depends on what the agency offers and what you’re willing to pay as the client. In my opinion, the “free bug fix” arrangement aligns the incentives of both parties more closely, and is both more difficult and profitable to implement on the agency end.

Regardless, the fundamental arrangement at play with hours-based maintenance contracts is that the client pays for any time used by the agency (whether that’s bugs, upgrades, security, etc) and as a byproduct doesn’t always have to pay the “full price” the agency would otherwise charge for every piece of work.

Okay, so we’ve covered why agencies typically bill for bug fixes under an hourly arrangement, and the risk/reward that presents you as the client.

That leads into the final question:

What about when there are a lot of bugs, though?

Hourly arrangements can start to break down if the client is being charged to fix a lot of bugs or defects, unfortunately.

In the original question that spawned this article, the hourly maintenance contract was being used almost exclusively to fix bugs and breaks caused by updates to the site. While I cannot say for sure whether or not this is “normal,” there could be a few factors at play:

A) The ratio of the support contract could be too small relative to the site’s original cost and complexity

One possible scenario is that the amount and frequency of bugs is “typical” relative to the size of the site, and the support contract is just not large enough to make headway on other pieces of work.

The classic rule of thumb is to budget at least 15% of your site’s initial cost as your annual budget for support and maintenance (not including additional upgrades). So if you paid $50,000 for your site, you’d need to set aside $7,500/year to keep it secure, maintained, and online. Any amount beyond that would go to upgrades over time.

Now, at Brooks Digital we have a very different viewpoint of how budget should be allocated for a data-driven website, but I’ll stick to the typical rule of thumb that would apply for this particular situation.

In this case, it’s worth running a basic sanity check to make sure your budget matches your expectations given the size and complexity of your site.

B) There could be poor ongoing management of “technical debt”

Technical debt is a metaphor for all of the shortcuts, hacks, and poor design choices made for a given software system that compromised its quality, usually in an attempt to meet a deadline. It can be an appropriate business decision to take on technical debt, but if such debt is allowed to grow, the lack of quality of the system may eventually make it too expensive to maintain. – DevIQ

A reality of software development is making frequent tradeoff decisions that balance the quality/longevity of the work being performed against the pressure of budget and deadlines that may prevent an ideal solution from being developed. Every website has technical debt in some form.

However, when an agency does not communicate about:

1. the amount of technical debt,
2. when it is being incurred, and
3. how it needs to be appropriately managed

…the interest payments can reach mammoth proportions and exhibit the same symptoms described in the original question: frequent, unintended bugs, and long resolution times.

C) The agency could not be highly competent in managing Drupal sites and/or their own internal development workflow

Lastly, it’s possible the agency is not experienced in managing Drupal sites and/or their internal development team or processes have various levels of inefficiency.

It might be worth asking them:

• What percentage of the sites you maintain are based on Drupal?
• Do most sites you maintain exhibit bugs this frequently?
• Is this a typical resolution time for most requests you receive from clients?

If your site is the exception, you can talk with the agency about how you better work together to improve your site and turnaround times.

If your experience is typical for them, you need to ask yourself whether it’s something you’d be happy with over the long-term.

What you can do about it

Here’s what I’d recommend to someone in this situation:

1. Ask the questions I outlined above to gauge the agency’s experience with your website technology and whether or not the bugs and turnaround times are normal for them.
5. If your experience is not the norm, explain that you want things to improve and ask them for ideas. Ask them about the amount of technical debt on the site. Ask them for their recommended course of action. Ask them how you can better work with them. Chances are, they want things to improve, too, and will be relieved that you asked.
6. If what you’re experiencing is normal, consider whether this is a relationship you’d be happy with over the long term. Then come to the table and try to work things out, but make sure you highlight that you can’t continue working with them if things stay the same.

Ultimately, if you aren’t happy with your agency, the benefit of the open source ecosystem is that you can switch providers at any time. While that can’t always happen overnight, as an organization you have the obligation to make the best choice for your organization’s long-term future.

If you’re exploring your options, don’t hesitate to get in touch. 🙂