Jason Pelker: web developers should seek retainers
Jason Pelker makes a good point about the frequency with which projects get underestimated:
90% of the time, the freelancer is going to get screwed on the estimate. My guess is that 9.9% of the time, the client gets screwed (I use the term loosely—as long as the site is completed within the contractual constraints of the project, the client is generally happy). That leaves 0.1% of all estimates that accurately reflected the correct amount of time it took to accomplish the project. Of course, any time valuable should to be taken with a grain of salt because what takes an hour today might take 90 minutes or 45 minutes tomorrow depending on all external factors, not the least of which is distraction.
The bigger point is that clients hate unexpected change, especially a price increase due to underestimation on your part. There are few things most likely to guarantee that you won’t be asked to do second project with a client than raising the cost of your invoice halfway through a project (in fact, most contracts aren’t going to permit this anyway, so again, you’ll likely eat the extra time and costs yourself, anyway).
Using a Retainer to Eliminate Guessing
Herein lies the beauty of the retainer block. You might already be using retainers after the project is complete for tasks like website maintenance or social media marketing (if you’re not, you should—it’s a great way to earn residual income).
I have suggested to a number of clients that they simply pay me a flat monthly fee, but then they worry about the months when not much is changing – why would they want to pay me then? Estimation is a point of pain in the relationship between developers and clients. It is difficult to educate the clients so that they can understand why things cost as much as they do. Its tragic how many times I’ve seen a potential client go with the lowest bidder, knowing full well that the bidder was planning on ripping the client off, because the price was far to low to do what the client actually wanted.
March 5th, 2010 at 4:38 pm
I had a one-on-one telephone session with Ryan Kovach yesterday about not leaving money on the table with clients, and now I’m thinking of calling this model “micro-retainers” since Ryan advocates using much larger retainers ($20,000+/year) to better sustain a web development business. You can Ryan’s article about tables/money on Woorkup: http://woorkup.com/2009/11/29/as-a-web-designer-are-you-leaving-money-on-the-table/ .
Anyway, I still advocate these “micro-retainers” for a number of circumstances, such as:
you’ll just been introduced to the client and you want to test out the working relationship
the client is a jerk and you want to do as little work for them as possible (in that case, you may want to think about firing the client outright. Getting rid of a difficult client is tough in the short-term but pays off richly in the long).
you’re doing work for a friend
The issue is that these micro-retainers aren’t going to generate a lot of cash (which is fine if you’re working for friend), unless the client gives you permission to burn through the hours freely (eventually, you will run out of work to do, though). It’s probably best to at least double your normal hourly rate and round up your tasks to the nearest half hour (within reason, of course). That way, all the little things you do for a client, like project manage and provide feedback to their emails, gets accounted for in the end. It’s also important to note that your availability is worth something to the client (probably a lot, actually).
It’s nice not to have to burn out on a project to make rent, as well as give yourself the ability to count research towards your clients’ workload, both of which work better in a monthly/yearly retainer setup.
March 6th, 2010 at 4:36 pm
Jason, thanks for writing.
The idea of a micro-retainer seems like an inevitable one in the era of micro-consulting. There are, of course, some legal issues that need to be dealt with – if someone starts paying you $200 a week as a “retainer” then you might have trouble convincing the IRS that you are an independent contractor – though if you have a dozen such clients, then that should be (I would hope) evidence in favor of the independence of your status.
Web or software development will always entail some risk, and I think there will always be some conflict between the developer and the client about who should pick up that risk. There are some advantages in being able to afford the risk, of course. I once had a client ask me if she could pay me after her startup was actually public – I said fine, and I did delayed billing her for the first 7 months of work. This allowed me to charge a higher-than-normal hourly rate, a kind of interest on the debt she was running. When she did finally pay me, the bill was large.
Of course, one can only run such a risk when one has some reason to trust the client. Most of the development situations that I’ve seen are exactly the opposite – the relationship is new and trust on both sides is limited. In that case, the smartest strategy seems to be to limit risk by breaking the project down into small pieces, dealing with small, fast iterations, and allowing small payments for small blocks of work.
You are right that a lot of background task, such as research, often don’t end up in the invoice, and a retainer would be more fair to the developer. I’d certainly like to hear more about your experiences with micro-retainers, as you gain more clients with whom you have those kinds of relationships.