Structuring Drupal Support Agreements

There are many ways that Requests for Proposals (RFP’s) do not work for web development projects. In most cases, RFP’s don’t work well for support either. In one case, I had a client present us with a list of specific projects they needed to have completed. We talked through the projects and examined their website to provide them with estimates on their specific needs. As we did further research, we found that we inherited spaghetti code. Then, the more items we addressed, the more got added to our list.

There are many ways that Drupal shops structure their support agreements.

Monthly Support Agreement Over a Fixed Term 

This is one of the most popular with Drupal shops, not necessarily that popular with clients. The Drupal shop would charge a monthly amount over a commitment period of, say, a year. The client receives X hours per month for that amount.

I have found that some Drupal vendors enforce a monthly “use-it-or-lose-it policy”. If you don’t use your hours this month, you’ve paid for hours you don’t use.

In defense of companies that like to work this way, they say that they will dedicate X hours of a developer to you every month. Whether you use the developer or not, they have dedicated a portion of their time to you.

Monarch Digital uses a variation of this support agreement. We provide a fixed budget amount of time and dollars monthly. We don’t usually have any term. It’s purely month to month. If the hours are not used in one month, they carry over to the future.

Used in this way, a monthly support agreement helps in budgeting support dollars and prioritizing projects within a specified number of hours monthly.

Price Over a Fixed Term

In this scenario, the Drupal shop invoices the client a fixed amount of money for a fixed amount of hours over a time period, say one year. The Drupal shop likes to get paid up front. (Don’t we all?)

Personally, I don’t like this structure. There is little incentive for the vendor to respond quickly, to perform in a timely fashion, or to perform at all.

Upfront Payment

As a client, you have a couple of small projects. Neither of you have done business in the past. The Drupal shop provides a client with an estimate. The client pays up front as they anticipate that this is all they will need of this vendor. The Drupal shop requires an upfront payment to assure that they will be paid for their work.

Monarch Digital has used this structure for small (less than three hours) one-time projects. Frankly, it is not very comfortable for either party. The client is paying for something they don’t have yet. The Drupal vendor knows this client relationship isn’t going anywhere.

Pay as You Go 

Interestingly enough, Drupal shops don’t propose this very often. Personally, I think this is the most sustainable for a long term relationship, given that the two parties mutually trust the respect one another.

Basically, the client pays for the time that the Drupal shop actually spends on the site.

In a less than ideal situation, a client could feel that the Drupal shop is incentivized to record more hours than they actually spend. A Drupal shop could feel that they could be left holding a bad receivable for as many as one or two months of support if the client decided not to pay. (Unfortunately, Monarch Digital has been in this situation.)

* * *

Ultimately, Monarch strives to work with clients and prospective clients to build contracts that work for everybody involved. Let's get to work!