This post continues an earlier post on site support, which we can summarize as follows:
- You’re going to need site support.
- You’re going to need a plan for site support.
Here, we cover one of your best options for securing ongoing support: creating a retainer arrangement with the same developer or team who built and deployed your existing web project.
“No Plan” Means Sad Devs
The problems come when you’re imposing sporadic, low-value support work that impedes your developer’s ability to make a living.
The reason you need a plan for site support is because the “I-have-no-plan” default of contacting your existing developer with urgent, infrequent support requests simply doesn’t work, for the reasons we outline in the previous post. To a lesser or greater extent, you’ll end up frazzling your developer or yourself.
So you might think that you shouldn’t bother your current developer once your project is done. On the contrary: your developer is the natural choice as your source of ongoing support. He or she understands the inner workings of your site better than anyone else, and your working relationship with him or her must be at least decent if you’ve finished a major project together and are coming back for more.
The problems only come about when you’re imposing sporadic, low-value support work that actually impedes your developer’s ability to make a living. Retainer arrangements can be a great cure for this.
How Retainer Arrangements Work
In a retainer arrangement, you prepay for a certain amount of your developer’s work—typically per-month, or else simply in a block of hours that never expire. This work might be at your developer’s normal rate, or at a discount or premium depending on the arrangement you negotiate.
Once you’ve paid, you can then draw against the hours you’ve purchased for support work. (However, if you are paying per month and you don’t use all that month’s hours, they simply expire unused.)
What to Include in an Arrangement
Retainer arrangements should specify how promptly the developer will respond to your support requests.
Retainer arrangements should include some form of agreement about how promptly the developer will respond to your support requests—such as “developer will work an initial hour within 12 hours of contact, and deliver a report on the problem if not solved within that hour.”
You’ll also want to be clear on what types of work are covered in the arrangement. For example, your developer may not want to include “build me a new page/section/website”-type work as covered—particularly if he or she is offering support hours at a discount.
Finally, you’ll want a plan for if you need to exceed your hours in a given period. You may stipulate that you can buy additional hours from your developer “à la carte,” perhaps not subject to the retainer discount (if any) or the quick turnaround and other terms covered in the original hours.
Why It Can Work Well
In general, retainer arrangements make support work substantially more appealing for developers, for the following reasons:
- Support income is now guaranteed, not one-off and sporadic. Recurring income is one of the most appealing things to developers in a feast-and-famine industry.
- The amount of support work the developer must expect to furnish is now capped, and your developer can now work within defined expectations around how quickly he or she addresses support requests.
- A retainer arrangement takes care of much of the overhead—communications, estimates, scheduling, invoicing—that can make support work unprofitable. Your developer can usually read your bug report, get to work, and bill almost the entire time he or she spends thinking about the problem.
In return, you’ll benefit in a number of ways:
- You’ll have set out clear expectations for urgent work, erasing the risk that your site will be down for a week while your developer finishes up an equally urgent and more lucrative project.
- Since you’ve paid upfront, you’ll be free from a “nickel-and-dime” mentality and you won’t feel shy about contacting your developer, erasing two problems that can cause you to postpone needed updates, bugfixes, and improvements.
- If your developer is continuing to learn and improve, he or she is also probably continuing to get more expensive. A retainer arrangement can lock in lower rates, and you may even be able to negotiate a discounted rate because of the appeal to your developer of recurring revenue.
A retainer arrangement is a lot like buying insurance: you’re paying now for problems you don’t yet have.
The only major drawback of a retainer arrangement is that you may pay for hours you don’t end up using.
A retainer arrangement is a lot like buying insurance, which means you’re paying now for problems you don’t yet have. In fact, you may never have them, although on average you will. Paying to insure against amorphous online risk may sting a bit, but like many forms of insurance, it can be an extremely smart choice, financially and every other way.
One cure for this is to see if your developer is willing to simply pre-sell a block of hours that never expire, rather than billing for a monthly retainer. Some developers may like this arrangement (since they know they’ll get paid a steady rate for every support hour they work), and some developers may not (since they’ll never get paid without working corresponding hours for it, as they could with a monthly retainer arrangement).
There’s also the obvious consideration that you’re buying the work of your existing developer. So if your developer is flaky, disrespectful, overpriced, or simply not terribly competent, you’ll probably want to pass on this arrangement.
Entering into a support retainer with your developer can be an outstanding way to lock down high-quality TLC for your web project into the foreseeable future. If you’re serious about your web presence, and can afford to pay something close to your developer’s hourly rate in small chunks moving forward, then there’s a great chance this is the right solution for you.
If, however, you feel a support retainer isn’t right for you, or would like to know your other options, we’ll be covering those in an upcoming post. Stay tuned!
Image Credits: Internet Archive Book Images