Charging clients for when Drupal security updates cause incompatibility issues

Our company charges an annual fee for identifying and applying security updates/patches for the Drupal sites we've designed, built, host and maintain.

I use this same approach as a feeelancer with very small clients. I charge yearly (and at a fixed price determined in advance) for that set of services.

My whole sales approach on this method is that my clients won't have to worry (both about problems with sites AND about unexpected costs). This is one of several reasons they are paying a lot more than the $125/year shared hosting they often had prior to coming to me. They just want their site to work; my clients are generally too small to have tech people on their paid staffs, and so I'm providing an end-to-end service for them.

I think the answer to the question is in pricing appropriately for the all-in-one hosting/code-security product, and then potentially raising the yearly inclusive hosting + security price, but only yearly. Think of yourself as an insurer; if a bad accident happened that you did have to pay for (e.g. a nasty contrib upgrade mess), you could recoup some of your loss through increased fees in the future.

One thing I do some of but want to do more: as I am working on the initial proposal, I want to more explicitly tie the complexity of a solution to increased annual hosting/cost-security fees. I'm pretty good at explaining that more complexity/code customization will likely lead to more fiddling which will mean ongoing expensive programming costs. But I also want to start emphasizing that there are also increased hosting/security etc. costs as well when implementing relatively more complex solutions and/or adding custom coding.

The bigger unsolved issue for me is Drupal 8. If Drupal 8 comes soon, I'm dead in the water. My customers are not going to be able to afford major upgrades (based on my limited and fraught experience so far upgrading sites from 6 to 7). I'm hoping for at least 2 more years before Drupal 8 is released. Or, as an alternative, if the Drupal community decided to continue to support Drupal 6 even with Drupal 8 released, I would be overjoyed. If, however, Drupal 8 comes out in the next year and Drupal 6 becomes unsupported, I don't have a clue as to what I would tell my customers who are on Drupal 6.

You might say, "duh, this release/support approach is not new." I think I have overestimated how much my clients can actually spend on their web projects and significantly underestimated how hard it would be to implement a major D6 - D7 upgrade.

But there must be a lot of other people in my situation.

I'm sorry if I've gotten off track a bit... it is connected to the original post, but maybe deserves its own thread.

best,

Shai

With every build contract I offer a support contract (retainer). I recommend a certain number of hours per month based on the complexity of the site at a reduced rate. It is then up to the client to decide how many hours they would like to buy. If they don't have enough hours because of a major conflict I advice the client that they have run out of hours and they will be charged a higher rate. In this way they run the risk, not me.

In order to sell a complete coverage package you must pad sufficiently to cover these kinds of issues and even then it is a educated betting game on your side. Propose it to them both ways and they will take the cheaper route where they take on the risk every time.

@pearrec, are your clients' sites on your server or theirs?

"They have to be dialed into our process." Right, that is the same for me. Are all of your clients on their own dedicated servers? Because it sounds like you give them the choice to not buy into your quarterly plan. In my case I have almost 15 clients on one server. They do not share any Drupal code, but they are sharing resources. I feel that I would be risking some clients if I didn't require them all to stay updated on security upgrades.

I just couldn't stand those repeated explanations of why I wanted to "upgrade" their site even though they wouldn't see any benefit. I'm not averse to explaining; I came from being a teacher. But it was a waste of time. I'd rather make that sales pitch as part of my getting the client initially and say, "this is the way I do business... here are the benefits." They sign on. Done. The yearly hosting/code security bill provides a yearly opportunity to review this.

But like the original poster, the gray areas are the hardest, like when a module security upgrade breaks the site. In my case, because I've made the initial sale on providing an end-to-end solution, if they aren't getting any new benefit, I have to pay for it.

p.s. I'd be interested to learn from others about the frequency with which a security update causes incompatibility issues with an existing site. How often does this happen (e.g. 10% of the time on average?), and whether, like us, you find that the solution might take only a few minutes to implement, or a good few hours. Anything more you/we can do to mitigate against this risk from a technical perspective, as opposed to a billing perspective? Because of course if we can minimise this risk from a technical perspective, then it reduces the need for an billing policy around it.

Interesting topic. I've only recently started offering general server/site maintenance services (in direct response to demand). Previously I only offered to maintain my custom code, and that done at an hourly rate (example upgrading a whole bunch of custom modules from D5 to D6.)

My approach with the relatively few sites I'm now maintaining is partially a technical one - all have a staging and live site - a duplicated installation (separate Drupal code and database.) So we run all upgrades on the staging site before touching the live site, if anything obvious breaks the live site is intact, (albeit perhaps insecure!) Then decisions can be taken relatively at leisure. Of course, it's always possible that something less than obvious gets broken, in which case we may not notice until it's "too late", but this approach at least avoids WSOD and similar problems where you then need you to rush around madly trying to fix it or restore from backup.

In practice, security updates are not always vital - quite often the particular situations needed to exploit a vulnerability doesn't/can't exist on a specific site. Many small sites have only a handful of registered users and all are trusted - many vulnerabilities are only exploitable by a logged-in user.

So, for now I charge for everything on a time basis (with a minimum hours retainer.) Of course clients want everything to be fixed-price, but it's not always viable. What about OS and LAMP upgrades? They might break a Drupal site too, albeit relatively unlikely. I don't think I would ever want to offer a fixed-price irrespective of what might break. I would put a disclaimer in the agreement, definitely.