If you can get the client to put you on retainer, go for it!
Agreements vary, but the general idea is that the client agrees to pay you for a fixed number of hours per month in exchange for guaranteed priority service. Sometimes they won't call you at all and the income is gravy. :-)
Our On Demand Support is only available to the clients who are having retainer options
This covers :
- Immediate response when site has application/infrastructure related issues
- On Demand Performance Tuning/Optimization.
- Priority Access to discuss Product Road map
- Regular review of Server and Application Logs for any security violations/ performance issues
We have Linux Certified professionals on board who provide 24x7 Monitoring and yes, we do get calls very rarely but when this happens, we respond very very quickly. On case to case basis, we even engage with other Drupal shops to get second opinion that best practices are consistently followed for all clients.
Gloscon Solutions Inc
Open Source Web 2.0 Development Company http://www.gloscon.com
T : 604.630.4292 (Canada)
T : 323.319.3609 (US)
Currently testing the waters here myself, so "subscribing" I guess.
Although it has to be said, after a few weeks, HOW many module updates are there normally?! Quite a few security updates as well. I personally think this forms the basis of a need for ongoing maintenance fees for priority sites, but I'm interested to know how to sell this as "open source", as it's really quite similar to charging a license fee for proprietary software - isn't it...?
As for updates, it depends of course on the Drupal version and which contributed modules you're using. Since 5.x is nearing the end of its life cycle in terms of releases, the updates (for both core and contributed modules) will become fewer and fewer.
I didn't say I was selling software. I said the situation "was similar" to buying software updates.
Windows XP -> Vista = upgrade fee
Drupal 5 -> Drupal 6 = maintenance fee
There's not much difference really. Regardless of whether or not 5.x is getting to EOL, there will arrive a crunch point where 6.x will be a prerequisite. Clearly that particular release is not so much slowing down as speeding up, in terms of releases.
This is really a case of "six of one, half a dozen of the other", in my opinion...
Either way, I had a "debate" with a client (the first one I approached with the retainer/maintenance fee proposal) and I really haven't come to any sensible conclusion about what to do.
I thought this sort of thing was de rigeur in the industry these days...?
You can charge whatever you want when dealing with open source, you just can't have a EULA that restricts the distribution of that software. Under the GNU license it is my understanding that you could create a drupal module and sell it but you couldn't sue that person if they went around and sold the same module bc your module is under that license. Now where it gets hazy is like you could create a google maps module but that doesn't mean google maps is open source just because you created a module to connect to their API.
I don't worry about that so much. I am creating an open source e-commerce module (http://drupal.org/project/role_subscription) and part of how I plan to monetize development is charging for support which many in the open source community do. There's plenty of ways to make money from open source.
Obviously in this discussion it's for custom web development/support using drupal as the platform.
It is most helpful. I am not selling support necessarily, I think this is a relative new paradigm for what I'm after, and that's a retainer for Drupal/PHP web development. The client pays pays a retainer and in return they get guaranteed availability month to month and a discounted rate for that amount of hours. The developer gets a steadier flow of income. The client signs the agreement bc they know they are going to have a steady flow of work and so they would sign the retainer for whatever the minimum amount of hours a month they would need the developer, otherwise they would look just for a freelancer but I think another benefit is to both the client and developer is that it is a more stable relationship then starting over with new freelancers every project and having to deal with scheduling when all your freelancers are tied up. We have this issue in our business Lynxmark.com, as we hire designers but we have to endure delays to get the designer we want sometimes for a project because they're tied up in other projects.
I've talked to a couple business owners and this is my rough draft of a retainer system. This would be the only way I do freelance, is to line up retainer agreements for the "X" amount of hours of work I would like a month. Your freedback is most welcome.
Normal rate $50/hr
Plan 1 - 20 hours a month, discount rate $45/hr and $900/mo retainer, excess hours bill at regular rate.
Plan 2 - 40 hrs a month, discount rate $40/hr and $1600/mo retainer, excess hours bill at regular rate.
Plan 3 - Under 20 hrs a month full rate of $50/hr but will reserve X amount of hours for that block of time a month.
The retainer fee is charged monthly and may be paid in 90-day increments at the beginning of the quarter if paying by check, monthly if paid by direct deposit.
The retainer fee is just the rate times the amount of hours, so a business wanting 20/hrs of development (eg drupal theming, drupal sites, module development, support, etc) a month min would have the floor of paying for 20 hrs and any excess hours would be billed at the normal rate and I, the developer would just invoice them (ala freshbooks) each month for excess work.
I think clients will pay for On Demand Support and knowing that there will be 24x7 Support rather than month to month hour bucket. In long term the monthly buckets can't renew if clients don't use them and they know that they are not using them.
But if they know they have a solid company with Drupal experts, Server experts, Performance Experts who can get on and address emergencies 24x7, they would certainly consider it. For high traffic sites upto 24 hours or more of down-time or malfunction and the impact it leaves on their visitors is of paramount importance and knowing that that is covered by some solid company with lot of experience and ample manpower would give them a comfort feeling.
I realize in the realm of IT that retainers usually indicate software or hardware support but this is a bit different.
I have done freelance work part-time for a few years now and retainers would be used mostly for employers like web shops that have a constant flow of new work coming in. Many of those shops especially the smaller ones either use an array of freelancers or part-time developers or a mix. I'm talking ab 90% of the work a month would be new development. There of course is support involved for existing applications, but I'm not talking about retainers for 24-hr technical support, that's not what I'm after.
Hi Jay,
Good thread – thanks for starting.
Here are a few thoughts:
* Why discount your rate for a retained arrangement? Remember you are providing your client with the most valuable commodity you have…your time. I’m sure you are going to provide them with the same level of service if they were on retainer or not. The clients who prepay each month have priority queuing in our production schedule and a guaranteed response time of less than 24 hours – they are essentially securing our availability. The plus for the client is it allows them to budget a set amount each month (no fluctuation).
* We will also advise clients that while the beauty of a CMS like Drupal allows for self-sufficiency websites are no longer a one-time capital expense. Rather, an effective website is an ongoing expenditure that you have to budget for on a year-round basis – retainers fit well into this model.
* We have added a caveat to our block of time or retainer agreement in that we allow clients to carry over unused hours from month to month. Conversely, they can borrow hours against the next month if they have a task that may cause them to go over the set amount of time they have. The hours will eventually expire (after 90 days) if they go unused, but our desire is to provide them services for every hour they pay for. Most clients will have a bad taste in their mouth when it comes to renewing if they paid you for time they ultimately did not fully utilize.
*Certainly I could not discount the rate but it's just a way to entice the employer to put you on retainer and it seems to be a common practice in various industries. I want it to be as attractive as possible because I would really like to do 90% of my freelance work on retainer agreements so as to have a stable source of income.
*You're absolutely right that websites take maintenance. For Lynxmark for example I run all of our sites off 1 install and I routinely go in and upgrade modules and the drupal core as enhancements and security fixes come. It can be quite the maintenance task to upgrade modules bc it requires some do diligence in testing all the sites that use those modules - but let's save that for another discussion. Suffice to say the retainer would include some support as well but the focus is on new development (for me at least).
*That is a really interesting idea is to all rollover hours, and I like the 90 day expiration. That is probably something I would throw in if the client is otherwise hesitant. My thought is that companies that care more about availability than getting the retainer hours perfect would err on the side of too many hours and the budget conscious companies would shoot more for the lower amount of hours and risk availability plus having to pay excess hours at the full rate. When I hire developers or designers for instance I am definitely the latter, controlling costs is more important to me in most cases. And so the company has the flexibility built-in to choose the amount of hours they feel comfortable with in the retainer agreement. From my perspective if they are very unsure ab the amount of hours they can provide month to month then I'm probably going to want to take my services elsewhere or just agree to a lower retainer agreement. Either way it would probably be fine. If they are paying monthly for a 40/hr retainer and are consistently only using 20 hours after a few months they could just switchover to a lower hour retainer. That is a very interesting nugget to offer.
$50/hr seems on the low-side to me, but I'm not really familiar with market rates for Drupal development - I'd be very interested in knowing people's opinions as to what market rates are. In my case I'm a Systems Architect / Developer, I don't do the graphic design angle. Also, being from the UK, maybe $50 seems low only because of the exchange rate situation. Back in the days when a dollar was almost worth a pound, $50/hr would have been a very reasonable rate.
As for the "retainer fee" principle, I think it's fine, so long as you deliver! What I mean is, a retainer fee should, to my mind, guarantee a client a certain level of availability. So basically they should pay the fee to gurantee that you will be available for them, if required, for up to x hours per month (or whatever period). The actual hours may or may not be charged on top, but you can't turn round and say "sorry, I'm too busy this month".
Jk, I guess whatever rate you can get. I see 40-50 a lot in contract jobs posted on big sites like monster and careerbuilder and based on my experience I think it's a fair rate. If I'm on the lower side I'm ok with that for now. I'd rather err on the side of lower than too high as I want to be able to secure work. It would be interesting to poll developers of different areas and experience and ask what they charge, maybe I'll do a survey!
You are absolutely correct on the retainer. If you are charging for your availability you need to be available otherwise you, as the developer are in a sense violating the contract. I keep very close track of my hours through freshbooks and so I think it's important as the developer to keep close watch of those hours and be sure to let the client know where you are on hours. I like freshbooks bc you can give the client access so they can keep track as well. I think as the developer to keep a good relationship you would want the client to know if haven't used up all their hours and it's close to the end of the month.
On another note it's up to the developer and client to determine what the appropriate response time is. I think with most web development you will be able to schedule meetings and demos and milestones, go live dates, etc in such a way as through good scheduling make sure you are available to the client and I would think you could keep in touch at least daily to respond to emails, questions. In my full-time job I'm used to juggling a lot of projects at once so that's helped prepare me.
I think it would be unrealistic for a client who's paying a 20 hr/mo retainer to demand your full attention for 4 straight business days if that isn't arranged ahead of time for example. I just don't see that happening really. I think the developer has to establish a trust relationship and be accessible and be a good scheduler, keep could track of hours and use an issue tracker for projects to keep the lines of communication open with clients and if they do good work then everything's good.
I'm filibustering but was last thought to reiterate this point. We had basically the opposite experience when we hired a freelancer for an API built on top of Amazon s3. He overscheduled, did not keep good communication, didn't answer emails, we didn't have an issue tracker, at the time we didn't have version control which would have helped. We gave him a generous timeline and he kept having delays and all these problems and it was months behind and we eventually gave up on the project after we had paid 2/3rds of the project price and have nothing to show for it.
So yes if you charge for availability, you'd best be available =)
Rates will go down as more resources from India/China build expertise. You can expect the average rates to be around $25-30/hr for mid sized projects. We have been regularly conducting workshops in India and are seeing hundreds of developers putting in efforts to pick up Drupal skills.
One other reason to consider is tight budgets because of current market conditions and also Ruby on Rails now has also hit the mainstream getting lot of interest from enterprises - although in somewhat different area but still people are talking Drupal v/s Ruby on Rails.
Independent US domestic senior web developers (10+ years web development experience including 3+ years w/Drupal) can command higher rates between $60-100 per hour. Drupal shops usually bill at $100-150 per hour.
In the short-term I'm not too concerned about overseas competition low-balling rates. Many US clients appreciate the value in working with highly experienced native English-speaking developers in US time zones. This could no-doubt change in coming years, which is why I am preparing my exit strategy now. I'm getting tired of being a hired gun and trading my time for money. I'm going to start putting my skills/expeirence to work for myself and am preparing to shift to a residual income business model.
Firstly, no offence intended to anybody with "50 seems on the low-side".
Agree with BM that native English speakers (regardless of which side of the Atlantic they're on and whether or not they know how to spell "colour" properly :) should, rightly, be able to charge more than China, India etc, at least when dealing with US/UK clients. Likewise a native French speaker has the edge when dealing with a French client. But it's not just about communication but also about culture. Years ago I was told that people from oriental cultures tend to be pretty lousy software designers - no disrespect intended, and it may be completely untrue, but certainly the people who wrote the OS for my cheap-and-cheerful DVD/HD video recorder had no idea about who to design a UI! Possibly, as native English speakers, we have the advantage that when programming we don't have to divert CPU power to thinking in a foreign language (if...then...for...).. dunno.. anyway, to get back on topic...
I was thinking of basing my rates on $90 as a base, obviously open to some negotiation depending on duration of project etc. Normally I would offer fixed-price for a well-defined project (have you ever had a well-defined project? :). I'm short on Drupal experience, only two years, but 20 years total dev. experience inlcuding database design, C etc, (mmm... plus 808x assembler and other incredibly useful skills.)
Perhaps stating the obvious, but $x/hour for a four-hour project is very cheap compared to $x/hour for a 400-hour project.
Yeah, I definitely meant no disrespect when it comes to lower rates.
When it comes to rates, charge as much as the market will bear. One's reputation, experience, specialties, etc. all come into play. It also depends in part on the type and size of the client. You can have different rates for non-profits, small companies and big companies. However, if you're too expensive the phone might not ring as much. If you're too cheap, it might be a sign of inexperience or lower quality. It depends on the length and quality of the project too. A long-term steady gig might deserve a discounted rate (when you consider the time saved from having to market yourself to new potential clients.) You might also give a discount when approached about working on a super fun and/or high profile project. On the other hand, less appealing gigs could be charged a premium rate because the work is less interesting.
That said, I have found that clients DO NOT like different rates from the same resource/vendor. It's very confusing if you have different rates for front-end development, back-end development, database work, etc.
Ya as far as overseas development I think that could be more of a player in the future but right now that's something I'm not too terribly concerned ab. I think there's a place for overseas development just as there is a place for domestic development.
I have worked with both, had some good experience and some not so good. One of the tricky things is the time gap. I actually lived in China for 2 years and did freelance while I was there so I kind of lived that for a time. I also picked up a lot on the differences btwn eastern and western thought.
All that aside I think I would agree with the main point that you let the market determine what you're rate is going to be and how much of a workload you want. In the past when I've wanted to ensure that I could get work I'd lower my rate. I've got a pretty strong portfolio and experience now so I've upped the rate some. I'm trying to nail down the price that can make my goals work for being self-employed while also trying to not overprice or under-price my rate. Too high and you don't get enough work, too low and you feel like you're leaving money on the table.
JK, any conclusions about "differences btwn eastern and western thought" ? Just curiosity.
Years ago I developed a simple philosophy about pricing. It goes like this: Consider a line-graph of "price" on the x-axis compared to "income" on the y-axis. Clearly the line starts at zero (a price of zero obviously means you make no money!) But it also ends at zero (too high a price means you'll get no business.) In the middle then, it's non-zero (hopefully!), and in fact it will have at least one, and possibly more than one peaks. So the question is, where is/are the peak or peaks? If there's only one, that's where you want to set your price. If there are more than one, you probably want to choose the highest one - highest income - or maybe the one which is the highest price, because that means less work for a high level of income. Simple, but food for thought.
I also agree that "what the market will bear" is generally the "right" price. (that's pretty much what all big companies, supermarkets, etc. do.) But the question still remains: how much is that?
Just thought, you could add another line to the graph - "workload" on Y vs "price" on X. It starts very high (price == zero means lots of work!) then reduces, eventually hits zero when the price is so high that you get no business at all. Somewhere along the way you pass the optimum income/workload point - that's where I want to be :)
Good stuff. Oh on eastern vs western thought particularly Western vs Chinese I don't want to over-generalize but in China at least even at the collegiate level "Rote Learning" (http://en.wikipedia.org/wiki/Rote_learning) is still a major, major player which I think discourages creativity and out of the box thinking, I've had similar experiences working with some overseas developers in the East, but again of course I'm not trying to generalize for billions of people, that has just been my experience.
My thought is that if you want to schedule say 3 weeks of vacation a year you as the self-employed consultant would need to probably plan more ahead of time those dates than most employees. I say that bc my idea would be to put the days you're out on a calendar that you share with clients that are you "black out dates" so that they know when scheduling milestones and go live dates and everything that you are unavailable for certain dates. I think as long as you get in your hours you would be fine and as long as the client is aware what dates you'll be out prior to agreement, it should be all good. Most clients are going to schedule go live dates around the holidays and taking a week off in july and whatnot I think would be fine if clients are well aware of the fact plenty ahead of time.
Just stay where the air is clean, the lifestyle is casual, the essentials are affordable, and you can get wi-fi. I can think of several places, and a travel agent can think of several more. Put most of your retainer in your IRA. Sounds idyllic, but also sounds possible. Does anybody want to rent a house?
Maybe obvious, but knowing of a few trusted people who could cover for you while your away would seem sensible. At least to handle support issues. Depends on the nature of the project of course, but if it's something fairly standard then why not? That way the client gets uninterrupted service and you get a break.
I think there is some gray area as far as sub-contracting work, in my mind when I hire people I want full disclosure on that sort of thing and so if I was going to do that in my mind I would have to a) trust and have worked with the sub-contractor and feel comfortable with them and b) inform the client ab the arrangement.
I am discussing based on the assumption of finding ongoing retainers but you could as the self-employed developer always do short term retainers where like a contract basically you agree on say 80 hrs a month for 2 months or something like that. To me making contracts like this makes more sense on both sides.
In the past we've hired freelancers based on a set project price and establish a timeline and milestones and it still becomes hazy when the project experiences delays and then it appears that person is perhaps taking on too much work even tho you tried to clear that this would need to be a priority and so on...
I like the contact being more explicit and based on hours. Your estimates are that this project can be done based on these hours, if the total hours of the project are 150, lets set it up a 2 month retainer at 75 hours each and that amount of time will be reserved both months for those 2 months and the completion date will be by such and such and go live date is set at such and such.
And then it's up to you as the employer and project manager to keep make sure it stays on schedule. I just think that doing it that way versus just saying OK $3000 for 6 weeks and paid upon completion or paid based on milestones, etc. - I do think though retainer agreements probably are better suited when there's already a trust and working relationship established, trying it out on just a random contract might not workout well.
Ok so there are obviously a few people interested in this thread, so I propose that we get our heads together and discuss what the viable options are that we as developers/agencies can present to clients.
I have up til now not enforced or even offered maintenance on a retainer basis, instead offering it on a "chunk-by-chunk" basis. It seems to me that there are certain sites (and indeed, clients) that can benefit from this working method. However, I am also conscious that because of the rate of progression of Drupal, it would be easy for clients' sites to become quickly outdated if they do not subscribe to some form of maintenance contract. I think it's fair to say that this money is not "wasted", nor is it a hidden charge, as long as the time being allotted/used is well spend and monitored.
There are obviously clients/situations where this isn't going to sit well, however - these situations would have to be dealt with on a case by case basis. For example, I had with a client to whom I mentioned (well after the project's initial completion) that they might want to consider a maintenance contract, and I was rebuffed quite strongly for trying to apply a "stealth tax" on the customer after they had "already paid for the site". I confess that I omitted to mention the possibility of ongoing maintenance at the start of the project, having assumed the client would be aware that a site with "moving parts" would require some after-sales care from time to time. That's one (simple) lesson learnt the hard way.
So, I think it would be nice if we could lay out some potential ways forward and perhaps make a generic plan of how best to deliver these services so as to make our lives easier, keep these sites up to date, and strengthen a lot of our business models. Perhaps we could determine best solutions for a few things? :
- how to charge for time based on the type/trust/etc of the project or client
- how to determine the type of maintenance offered to a particular client - what options should you have in your arsenal to offer them?
- for ongoing retainer contracts, how to determine the amount of time a client requires per week/month/whatever
- how to address this issue to the client during the spec/pricing process
- how to address the issue of major releases (moving from 5 to 6 is potentially very time consuming, for example)
- how to present the client with the idea that modules are constantly going out of date, and what the benefits of constant updating are
It sounds like you're talking mostly ab maintenance contract.
In my mind the retainer agreement for me would be mostly new development but of course could include maintenance, that's just up to the client.
I would just indicate the level of difficulty and time for updating modules and the core, especially for major release updates such as 5 to 6. For normal upgrades you still have issues as far as how many sites run off of that one install, how critical are those sites, how critical is the module being updated, how much time etc. I update our multi-site install often for our lynxmark sites, but we're only hosting ab half a dozen and so it's not that big of a deal but if you're hosting dozens of sites, sometimes module updates can have big implications. You would need to do extensive testing, so in that case it just depends on how the client views the benefit gained in those updates.
Now for migrating from 5 to 6 I wouldn't recommend doing that in bulk, I would move one site over at a time and even then only when there's good reason to do so. That takes a lot of time and effort per site so I would only do that when say 6 has a lot of new features that the client feels is worth the money to upgrade.
I wouldn't try to "push" constant updating of sites bc each update could potential cause instability, so I would recommend security updates as high priority, otherwise it's case by case basis in my mind.
Perhaps now would be a good time to push for a Drupal "Business Issues" group on g.d.o or something?
It seems to me that there are quite a few things that need ironing out where Drupal is a "little but different" from the rest of the crowd. Namely, this issue, hosting, the rate of development, etc...
I'll join! Kind of related - is there any kind of "rating" system for Drupal developers (would we even want one?) - I mean, something like elance - www.elance.com - worth checking out if you don't know it - allows clients to rate providers. This strikes me as a generally good thing, although can cause problems for new providers starting up, as even if they are able to provide high quality service, they don't have ratings to prove it.
I'll have a word with some of the "right people" tomorrow and suggest this. It might be off topic enough that it's not accepted, but personally I feel it has some merit, so I'll give it a shot.
With any of those, be it from guru or elance or anywhere is that people learn how to game the system and figure out a way to get bogus reviews + earnings to catapult them to the top. Probably the same companies that spam you with bids so that they're bidding on every project and thus those rating systems lose credibility. I think it's one of those things where there's not a perfect rating system so for companies they just have to do their research the old fashion way, references, portfolio, resume, etc to determine who's a good candidate and then keep the ones that pan out.
Yeah, rating systems are tricky. It only takes one disgruntled client to damage a provider's reputation.
I think clients should only be able to offer positive recommendations. It's like the old saying goes, "If you have nothing nice to say, don't say anything at all."
At the competition of the project, the client is presented with a form that states something like, "The project was completed to my satisfaction. I would recommend this provider to others." with an "Agree" and "Disagree" button. The response is recorded, but only affirmative responses show in the provider's recommendation count. Assuming the client clicks "Agree", the form could also include a checkbox with the text, "I am happy to serve as a reference for this provider." A provider who continually provides poor service will fail to accumulate recommendations and references.
Agree with both the above - a ratings system is only valuable if it shows genuine information - but that's a design and implementation problem, I think there could be a lot of value in a proper ratings system.
Another system I know allows you to rate the rating! i.e. when you get a rating, it says "Is this rating fair/unfair?" etc. I'm not sure how it then processes that result. This would leaves the door open for you to say that all good ratings are fair and any bad ratings are unfair, so my guess is that it does not affect your own rating but maybe affects others. Perhaps our collective brains could design a functional ratings system - there are existing modules of course but too simplistic for this I think.
Just off the top of my head:-
ClientA rates ProviderA giving a good rating. (10/10)
ClientB rates ProviderA giving a bad rating. (0/10)
--> ProviderA now has an average rating of 10/20.
ClientB also rates ProviderB giving a bad rating, but ProviderB says this is "unfair" -- this has *no* affect on ProviderB's own rating, but reduces the "weight" of the bad rating for ProviderA from 0/10 to 0/5.... Thus ProviderA now has a better rating of 10/15 instead of 10/20. Ok, it's still open to abuse - the two Providers could be the same person, or two people collaborating etc. But I think if the whole thing is relatively small (not a huge system like elance) it could work well.
... um, on the other hand, maybe that's just too much - a simple comments system where clients say "thanks for the great work" etc, might be better, and new clients can read through the comments.
Rating *clients* can be valuable (do they pay on time, do they keep changing the spec, are they reasonable when unforeseeable difficulties crop up...)
Maybe a "referral" system? - In other areas of work that I'm involved with, I'm forever being asked "do I know anybody else (who's available)".
Much of this assumes a many-to-many relationship of clients to providers, which is probably not the case here. So I've concluded I'm talking gibberish.. I'll shut up now :)
On the internet, as well as elsewhere, anybody can say whatever they want to, making truth hard to discern. I hope the human race is able to adapt to this, or else we're done for. I haven't installed fivestar or other rating modules, but I hope that they're capable of only accepting one rating per user, with the latest overwriting the old. This capability, plus the capability of deleting users, is probably the best we can hope for. And yes, let people comment to explain their rating.
@jaykali - Start one. I think there's a lot of jobs posted because that fits under the subject of "consultants and business". But it doesn't mean it has to be all jobs. Just create a new discussion and there you go.
Not sure how it will do. I only see topics on that main page, seems like they will get lost after a while. I don't see a central place there to look at all discussions.
Maybe worth remembering, anybody big (IBM, Oracle, etc, etc) would always include ongoing fees in any significant project. Maintenance, support, upgrades, security auditing, etc. The majority if not all medium-sized providers will do the same. So why any difference just because you're a one-man band? This is in answer to how to convince the client as to why pay for ongoing aspects - basically because is has to be that way.
Another way forward, if you can handle the cash-flow implications, is to have *everything* bundled into an ongoing fee. By this I mean *no* separate set up, design, development charges - you create whatever it is that they want, and they pay $x per month for using it, *forever*, and that of course includes support, updates, etc. This assumes that you control the server where its all running, otherwise they could just take a copy of the system and do a runner. This approach won't work for everybody nor all projects, but to a business client it should be an attractive alternative. In some cases, it also allows a company to avoid budget restrictions, e.g. they can't spend $5000 but they can spend $500 per month.
I used the above approach very successfully in my own software house (it was around for thirteen years and employed more than 15 people) - we produced a type of CRM system - it could either be "bought" (anything from $10k to $50k) plus ongoing support/maintenance fees or "rented" - a single monthly fee with everything included. The second option was very popular. You have to get the price right of course!
Yeah I agree that this is an option, certainly for some people. Of course, in order to make this work, there has to be a minimum contract span, which inevitably works out more expensive in the long run (ie the length of the contract). Then you have to convince the client to keep paying after the fact. This is a darn site more simple if you are providing a "service" rather than "goods" - a website could essentially be viewed as a one-off item. I personally think that's a stupid way to look at it, but that's what I'm seeing in the SME marketplace.
I have to say tho, If I could muster a service based business together I'd probably be doing exactly the above...
For "safety" as the provider, maybe yes. But actually we had minimum contract period. The thinking went like this:
* Does this client need what we have? (a genuine business need.)
* Do we have the best solution, or at least one of the best solutions?
* Are we dealing with the right person?
If we believed that we could answer "yes" to all three, we went ahead. The risk, in reality was minimal because we had a great product. The fact that there was no minimum contract period made it much easier for the client to say "yes". Once they were using our system they were pretty much "locked-in" -> ongoing income.
Of course it's up to each developer to decide how they want to do business but with my retainer concept I would most likely not require a minimum contract span for businesses that set up direct deposit.
Under my plan I would, however, require a 3 month pre-payment of the retainer if the business does not do direct deposit. This is the main reason why. Dave Ramsey, financial guru, says that a collections problem is a sales problem. Unfortunately there are clients who won't pay so in my mind the best way to insure payment is to set up direct deposit which to me solidifies a bit the idea that you'll probably get paid on time, if the direct deposit doesn't go through you suspend service until the account is up to date. What I like also ab direct deposit is that it implies an ongoing relationship which I like.
With the pre-payment option for businesses that don't want to do direct deposit that is a way for the developer to be sure he/she gets paid if they aren't on direct deposit.
In my experience doing freelance contracts where you get paid in increments or when the site goes live usually lead to delays in payment. If it's your livelihood then I think having an agreed upon payment system makes a lot more sense.
This is not for newcomers. I think new freelancers are left with whatever they can get. For those of us with a bit more experience and a solid portfolio and resume, I think there's more room for better contracts.
To me the arrangement of the retainer can be enticing for clients because it a) insures availability for X amount of time b) is a discounted rate for those hours c) establishes an ongoing relationship so that they can count on you as a resource and d) with my plan doesn't require a long commitment.
One last note on rates, I personally like simple so my rate would be just a flat rate whether it be for new development, support, installs, etc. - I think for consultants it makes sense not to over-complicate rates because doing so can look contrived.
Comments
We do
We do for a few clients. Depends on their needs.
Chris Winn
Eshilon Design Inc
www.eshilon.com
HI Jay ,
We are already working on similar business model
Hit me in skype lets us discuss in detail so that we are on the same page ..
With Regards,
SKR
skype :skr.bdm
retainer fees
If you can get the client to put you on retainer, go for it!
Agreements vary, but the general idea is that the client agrees to pay you for a fixed number of hours per month in exchange for guaranteed priority service. Sometimes they won't call you at all and the income is gravy. :-)
It's available
I offer it to clients with a 20% discount on my normal hourly rate, although nobody's had the need for it yet.
We do have this with multiple clients
Our On Demand Support is only available to the clients who are having retainer options
This covers :
- Immediate response when site has application/infrastructure related issues
- On Demand Performance Tuning/Optimization.
- Priority Access to discuss Product Road map
- Regular review of Server and Application Logs for any security violations/ performance issues
We have Linux Certified professionals on board who provide 24x7 Monitoring and yes, we do get calls very rarely but when this happens, we respond very very quickly. On case to case basis, we even engage with other Drupal shops to get second opinion that best practices are consistently followed for all clients.
Gloscon Solutions Inc
Open Source Web 2.0 Development Company
http://www.gloscon.com
T : 604.630.4292 (Canada)
T : 323.319.3609 (US)
Hm
Currently testing the waters here myself, so "subscribing" I guess.
Although it has to be said, after a few weeks, HOW many module updates are there normally?! Quite a few security updates as well. I personally think this forms the basis of a need for ongoing maintenance fees for priority sites, but I'm interested to know how to sell this as "open source", as it's really quite similar to charging a license fee for proprietary software - isn't it...?
You're providing a service...
...not selling software.
As for updates, it depends of course on the Drupal version and which contributed modules you're using. Since 5.x is nearing the end of its life cycle in terms of releases, the updates (for both core and contributed modules) will become fewer and fewer.
You misunderstand...
I didn't say I was selling software. I said the situation "was similar" to buying software updates.
Windows XP -> Vista = upgrade fee
Drupal 5 -> Drupal 6 = maintenance fee
There's not much difference really. Regardless of whether or not 5.x is getting to EOL, there will arrive a crunch point where 6.x will be a prerequisite. Clearly that particular release is not so much slowing down as speeding up, in terms of releases.
This is really a case of "six of one, half a dozen of the other", in my opinion...
Either way, I had a "debate" with a client (the first one I approached with the retainer/maintenance fee proposal) and I really haven't come to any sensible conclusion about what to do.
I thought this sort of thing was de rigeur in the industry these days...?
You might want to look at
You might want to look at Acquia's business model. Looks like updates is what Spokes is all about.
Yeah
That was partly my point, I sort of forgot to mention... :)
Managed drupal installs. Been thinking about it for ages. They got there first tho...
Also regarding open source
You can charge whatever you want when dealing with open source, you just can't have a EULA that restricts the distribution of that software. Under the GNU license it is my understanding that you could create a drupal module and sell it but you couldn't sue that person if they went around and sold the same module bc your module is under that license. Now where it gets hazy is like you could create a google maps module but that doesn't mean google maps is open source just because you created a module to connect to their API.
I don't worry about that so much. I am creating an open source e-commerce module (http://drupal.org/project/role_subscription) and part of how I plan to monetize development is charging for support which many in the open source community do. There's plenty of ways to make money from open source.
Obviously in this discussion it's for custom web development/support using drupal as the platform.
Thanks for the feedback!
It is most helpful. I am not selling support necessarily, I think this is a relative new paradigm for what I'm after, and that's a retainer for Drupal/PHP web development. The client pays pays a retainer and in return they get guaranteed availability month to month and a discounted rate for that amount of hours. The developer gets a steadier flow of income. The client signs the agreement bc they know they are going to have a steady flow of work and so they would sign the retainer for whatever the minimum amount of hours a month they would need the developer, otherwise they would look just for a freelancer but I think another benefit is to both the client and developer is that it is a more stable relationship then starting over with new freelancers every project and having to deal with scheduling when all your freelancers are tied up. We have this issue in our business Lynxmark.com, as we hire designers but we have to endure delays to get the designer we want sometimes for a project because they're tied up in other projects.
I've talked to a couple business owners and this is my rough draft of a retainer system. This would be the only way I do freelance, is to line up retainer agreements for the "X" amount of hours of work I would like a month. Your freedback is most welcome.
Normal rate $50/hr
Plan 1 - 20 hours a month, discount rate $45/hr and $900/mo retainer, excess hours bill at regular rate.
Plan 2 - 40 hrs a month, discount rate $40/hr and $1600/mo retainer, excess hours bill at regular rate.
Plan 3 - Under 20 hrs a month full rate of $50/hr but will reserve X amount of hours for that block of time a month.
The retainer fee is charged monthly and may be paid in 90-day increments at the beginning of the quarter if paying by check, monthly if paid by direct deposit.
The retainer fee is just the rate times the amount of hours, so a business wanting 20/hrs of development (eg drupal theming, drupal sites, module development, support, etc) a month min would have the floor of paying for 20 hrs and any excess hours would be billed at the normal rate and I, the developer would just invoice them (ala freshbooks) each month for excess work.
On Demand Support is more relevant
I think clients will pay for On Demand Support and knowing that there will be 24x7 Support rather than month to month hour bucket. In long term the monthly buckets can't renew if clients don't use them and they know that they are not using them.
But if they know they have a solid company with Drupal experts, Server experts, Performance Experts who can get on and address emergencies 24x7, they would certainly consider it. For high traffic sites upto 24 hours or more of down-time or malfunction and the impact it leaves on their visitors is of paramount importance and knowing that that is covered by some solid company with lot of experience and ample manpower would give them a comfort feeling.
Roshan
http://www.gloscon.com
Actually I'm not talking support
I realize in the realm of IT that retainers usually indicate software or hardware support but this is a bit different.
I have done freelance work part-time for a few years now and retainers would be used mostly for employers like web shops that have a constant flow of new work coming in. Many of those shops especially the smaller ones either use an array of freelancers or part-time developers or a mix. I'm talking ab 90% of the work a month would be new development. There of course is support involved for existing applications, but I'm not talking about retainers for 24-hr technical support, that's not what I'm after.
Retainer discussion...
Hi Jay,
Good thread – thanks for starting.
Here are a few thoughts:
* Why discount your rate for a retained arrangement? Remember you are providing your client with the most valuable commodity you have…your time. I’m sure you are going to provide them with the same level of service if they were on retainer or not. The clients who prepay each month have priority queuing in our production schedule and a guaranteed response time of less than 24 hours – they are essentially securing our availability. The plus for the client is it allows them to budget a set amount each month (no fluctuation).
* We will also advise clients that while the beauty of a CMS like Drupal allows for self-sufficiency websites are no longer a one-time capital expense. Rather, an effective website is an ongoing expenditure that you have to budget for on a year-round basis – retainers fit well into this model.
* We have added a caveat to our block of time or retainer agreement in that we allow clients to carry over unused hours from month to month. Conversely, they can borrow hours against the next month if they have a task that may cause them to go over the set amount of time they have. The hours will eventually expire (after 90 days) if they go unused, but our desire is to provide them services for every hour they pay for. Most clients will have a bad taste in their mouth when it comes to renewing if they paid you for time they ultimately did not fully utilize.
Thanks, Dave
www.mediacurrent.com
Good thoughts
*Certainly I could not discount the rate but it's just a way to entice the employer to put you on retainer and it seems to be a common practice in various industries. I want it to be as attractive as possible because I would really like to do 90% of my freelance work on retainer agreements so as to have a stable source of income.
*You're absolutely right that websites take maintenance. For Lynxmark for example I run all of our sites off 1 install and I routinely go in and upgrade modules and the drupal core as enhancements and security fixes come. It can be quite the maintenance task to upgrade modules bc it requires some do diligence in testing all the sites that use those modules - but let's save that for another discussion. Suffice to say the retainer would include some support as well but the focus is on new development (for me at least).
*That is a really interesting idea is to all rollover hours, and I like the 90 day expiration. That is probably something I would throw in if the client is otherwise hesitant. My thought is that companies that care more about availability than getting the retainer hours perfect would err on the side of too many hours and the budget conscious companies would shoot more for the lower amount of hours and risk availability plus having to pay excess hours at the full rate. When I hire developers or designers for instance I am definitely the latter, controlling costs is more important to me in most cases. And so the company has the flexibility built-in to choose the amount of hours they feel comfortable with in the retainer agreement. From my perspective if they are very unsure ab the amount of hours they can provide month to month then I'm probably going to want to take my services elsewhere or just agree to a lower retainer agreement. Either way it would probably be fine. If they are paying monthly for a 40/hr retainer and are consistently only using 20 hours after a few months they could just switchover to a lower hour retainer. That is a very interesting nugget to offer.
Is $50-hr the "market rate"?
$50/hr seems on the low-side to me, but I'm not really familiar with market rates for Drupal development - I'd be very interested in knowing people's opinions as to what market rates are. In my case I'm a Systems Architect / Developer, I don't do the graphic design angle. Also, being from the UK, maybe $50 seems low only because of the exchange rate situation. Back in the days when a dollar was almost worth a pound, $50/hr would have been a very reasonable rate.
As for the "retainer fee" principle, I think it's fine, so long as you deliver! What I mean is, a retainer fee should, to my mind, guarantee a client a certain level of availability. So basically they should pay the fee to gurantee that you will be available for them, if required, for up to x hours per month (or whatever period). The actual hours may or may not be charged on top, but you can't turn round and say "sorry, I'm too busy this month".
Rub it in why don't you
Jk, I guess whatever rate you can get. I see 40-50 a lot in contract jobs posted on big sites like monster and careerbuilder and based on my experience I think it's a fair rate. If I'm on the lower side I'm ok with that for now. I'd rather err on the side of lower than too high as I want to be able to secure work. It would be interesting to poll developers of different areas and experience and ask what they charge, maybe I'll do a survey!
You are absolutely correct on the retainer. If you are charging for your availability you need to be available otherwise you, as the developer are in a sense violating the contract. I keep very close track of my hours through freshbooks and so I think it's important as the developer to keep close watch of those hours and be sure to let the client know where you are on hours. I like freshbooks bc you can give the client access so they can keep track as well. I think as the developer to keep a good relationship you would want the client to know if haven't used up all their hours and it's close to the end of the month.
On another note it's up to the developer and client to determine what the appropriate response time is. I think with most web development you will be able to schedule meetings and demos and milestones, go live dates, etc in such a way as through good scheduling make sure you are available to the client and I would think you could keep in touch at least daily to respond to emails, questions. In my full-time job I'm used to juggling a lot of projects at once so that's helped prepare me.
I think it would be unrealistic for a client who's paying a 20 hr/mo retainer to demand your full attention for 4 straight business days if that isn't arranged ahead of time for example. I just don't see that happening really. I think the developer has to establish a trust relationship and be accessible and be a good scheduler, keep could track of hours and use an issue tracker for projects to keep the lines of communication open with clients and if they do good work then everything's good.
I'm filibustering but was last thought to reiterate this point. We had basically the opposite experience when we hired a freelancer for an API built on top of Amazon s3. He overscheduled, did not keep good communication, didn't answer emails, we didn't have an issue tracker, at the time we didn't have version control which would have helped. We gave him a generous timeline and he kept having delays and all these problems and it was months behind and we eventually gave up on the project after we had paid 2/3rds of the project price and have nothing to show for it.
So yes if you charge for availability, you'd best be available =)
Rates likely to go down!
Rates will go down as more resources from India/China build expertise. You can expect the average rates to be around $25-30/hr for mid sized projects. We have been regularly conducting workshops in India and are seeing hundreds of developers putting in efforts to pick up Drupal skills.
One other reason to consider is tight budgets because of current market conditions and also Ruby on Rails now has also hit the mainstream getting lot of interest from enterprises - although in somewhat different area but still people are talking Drupal v/s Ruby on Rails.
One must find ways to move up the value chain!
Roshan
http://www.gloscon.com
http://drupalcamp08.drupalindia.in <- Drupal Camp in India - 8 to 10 August.
US Domestic Billable Rates
Independent US domestic senior web developers (10+ years web development experience including 3+ years w/Drupal) can command higher rates between $60-100 per hour. Drupal shops usually bill at $100-150 per hour.
In the short-term I'm not too concerned about overseas competition low-balling rates. Many US clients appreciate the value in working with highly experienced native English-speaking developers in US time zones. This could no-doubt change in coming years, which is why I am preparing my exit strategy now. I'm getting tired of being a hired gun and trading my time for money. I'm going to start putting my skills/expeirence to work for myself and am preparing to shift to a residual income business model.
Rates
Firstly, no offence intended to anybody with "50 seems on the low-side".
Agree with BM that native English speakers (regardless of which side of the Atlantic they're on and whether or not they know how to spell "colour" properly :) should, rightly, be able to charge more than China, India etc, at least when dealing with US/UK clients. Likewise a native French speaker has the edge when dealing with a French client. But it's not just about communication but also about culture. Years ago I was told that people from oriental cultures tend to be pretty lousy software designers - no disrespect intended, and it may be completely untrue, but certainly the people who wrote the OS for my cheap-and-cheerful DVD/HD video recorder had no idea about who to design a UI! Possibly, as native English speakers, we have the advantage that when programming we don't have to divert CPU power to thinking in a foreign language (if...then...for...).. dunno.. anyway, to get back on topic...
I was thinking of basing my rates on $90 as a base, obviously open to some negotiation depending on duration of project etc. Normally I would offer fixed-price for a well-defined project (have you ever had a well-defined project? :). I'm short on Drupal experience, only two years, but 20 years total dev. experience inlcuding database design, C etc, (mmm... plus 808x assembler and other incredibly useful skills.)
Perhaps stating the obvious, but $x/hour for a four-hour project is very cheap compared to $x/hour for a 400-hour project.
More info about "market rates" please.
rates cont.
Yeah, I definitely meant no disrespect when it comes to lower rates.
When it comes to rates, charge as much as the market will bear. One's reputation, experience, specialties, etc. all come into play. It also depends in part on the type and size of the client. You can have different rates for non-profits, small companies and big companies. However, if you're too expensive the phone might not ring as much. If you're too cheap, it might be a sign of inexperience or lower quality. It depends on the length and quality of the project too. A long-term steady gig might deserve a discounted rate (when you consider the time saved from having to market yourself to new potential clients.) You might also give a discount when approached about working on a super fun and/or high profile project. On the other hand, less appealing gigs could be charged a premium rate because the work is less interesting.
That said, I have found that clients DO NOT like different rates from the same resource/vendor. It's very confusing if you have different rates for front-end development, back-end development, database work, etc.
Wow great discussion
Ya as far as overseas development I think that could be more of a player in the future but right now that's something I'm not too terribly concerned ab. I think there's a place for overseas development just as there is a place for domestic development.
I have worked with both, had some good experience and some not so good. One of the tricky things is the time gap. I actually lived in China for 2 years and did freelance while I was there so I kind of lived that for a time. I also picked up a lot on the differences btwn eastern and western thought.
All that aside I think I would agree with the main point that you let the market determine what you're rate is going to be and how much of a workload you want. In the past when I've wanted to ensure that I could get work I'd lower my rate. I've got a pretty strong portfolio and experience now so I've upped the rate some. I'm trying to nail down the price that can make my goals work for being self-employed while also trying to not overprice or under-price my rate. Too high and you don't get enough work, too low and you feel like you're leaving money on the table.
More about rates
JK, any conclusions about "differences btwn eastern and western thought" ? Just curiosity.
Years ago I developed a simple philosophy about pricing. It goes like this: Consider a line-graph of "price" on the x-axis compared to "income" on the y-axis. Clearly the line starts at zero (a price of zero obviously means you make no money!) But it also ends at zero (too high a price means you'll get no business.) In the middle then, it's non-zero (hopefully!), and in fact it will have at least one, and possibly more than one peaks. So the question is, where is/are the peak or peaks? If there's only one, that's where you want to set your price. If there are more than one, you probably want to choose the highest one - highest income - or maybe the one which is the highest price, because that means less work for a high level of income. Simple, but food for thought.
I also agree that "what the market will bear" is generally the "right" price. (that's pretty much what all big companies, supermarkets, etc. do.) But the question still remains: how much is that?
Workload vs price
Just thought, you could add another line to the graph - "workload" on Y vs "price" on X. It starts very high (price == zero means lots of work!) then reduces, eventually hits zero when the price is so high that you get no business at all. Somewhere along the way you pass the optimum income/workload point - that's where I want to be :)
I second that thought
Good stuff. Oh on eastern vs western thought particularly Western vs Chinese I don't want to over-generalize but in China at least even at the collegiate level "Rote Learning" (http://en.wikipedia.org/wiki/Rote_learning) is still a major, major player which I think discourages creativity and out of the box thinking, I've had similar experiences working with some overseas developers in the East, but again of course I'm not trying to generalize for billions of people, that has just been my experience.
Also a tangent but relevant discussion - handling vacation
My thought is that if you want to schedule say 3 weeks of vacation a year you as the self-employed consultant would need to probably plan more ahead of time those dates than most employees. I say that bc my idea would be to put the days you're out on a calendar that you share with clients that are you "black out dates" so that they know when scheduling milestones and go live dates and everything that you are unavailable for certain dates. I think as long as you get in your hours you would be fine and as long as the client is aware what dates you'll be out prior to agreement, it should be all good. Most clients are going to schedule go live dates around the holidays and taking a week off in july and whatnot I think would be fine if clients are well aware of the fact plenty ahead of time.
Who needs vacation?
Just stay where the air is clean, the lifestyle is casual, the essentials are affordable, and you can get wi-fi. I can think of several places, and a travel agent can think of several more. Put most of your retainer in your IRA. Sounds idyllic, but also sounds possible. Does anybody want to rent a house?
I've done work on the beach in Thailand if that counts
Via satellite internet on internet cafe computers and it wasn't that fun =)
I do enjoy a vacation now and again =)
Handling vacation
Maybe obvious, but knowing of a few trusted people who could cover for you while your away would seem sensible. At least to handle support issues. Depends on the nature of the project of course, but if it's something fairly standard then why not? That way the client gets uninterrupted service and you get a break.
I suppose
I think there is some gray area as far as sub-contracting work, in my mind when I hire people I want full disclosure on that sort of thing and so if I was going to do that in my mind I would have to a) trust and have worked with the sub-contractor and feel comfortable with them and b) inform the client ab the arrangement.
Another point
I am discussing based on the assumption of finding ongoing retainers but you could as the self-employed developer always do short term retainers where like a contract basically you agree on say 80 hrs a month for 2 months or something like that. To me making contracts like this makes more sense on both sides.
In the past we've hired freelancers based on a set project price and establish a timeline and milestones and it still becomes hazy when the project experiences delays and then it appears that person is perhaps taking on too much work even tho you tried to clear that this would need to be a priority and so on...
I like the contact being more explicit and based on hours. Your estimates are that this project can be done based on these hours, if the total hours of the project are 150, lets set it up a 2 month retainer at 75 hours each and that amount of time will be reserved both months for those 2 months and the completion date will be by such and such and go live date is set at such and such.
And then it's up to you as the employer and project manager to keep make sure it stays on schedule. I just think that doing it that way versus just saying OK $3000 for 6 weeks and paid upon completion or paid based on milestones, etc. - I do think though retainer agreements probably are better suited when there's already a trust and working relationship established, trying it out on just a random contract might not workout well.
Business processes & planning - how to tackle this issue
Ok so there are obviously a few people interested in this thread, so I propose that we get our heads together and discuss what the viable options are that we as developers/agencies can present to clients.
I have up til now not enforced or even offered maintenance on a retainer basis, instead offering it on a "chunk-by-chunk" basis. It seems to me that there are certain sites (and indeed, clients) that can benefit from this working method. However, I am also conscious that because of the rate of progression of Drupal, it would be easy for clients' sites to become quickly outdated if they do not subscribe to some form of maintenance contract. I think it's fair to say that this money is not "wasted", nor is it a hidden charge, as long as the time being allotted/used is well spend and monitored.
There are obviously clients/situations where this isn't going to sit well, however - these situations would have to be dealt with on a case by case basis. For example, I had with a client to whom I mentioned (well after the project's initial completion) that they might want to consider a maintenance contract, and I was rebuffed quite strongly for trying to apply a "stealth tax" on the customer after they had "already paid for the site". I confess that I omitted to mention the possibility of ongoing maintenance at the start of the project, having assumed the client would be aware that a site with "moving parts" would require some after-sales care from time to time. That's one (simple) lesson learnt the hard way.
So, I think it would be nice if we could lay out some potential ways forward and perhaps make a generic plan of how best to deliver these services so as to make our lives easier, keep these sites up to date, and strengthen a lot of our business models. Perhaps we could determine best solutions for a few things? :
- how to charge for time based on the type/trust/etc of the project or client
- how to determine the type of maintenance offered to a particular client - what options should you have in your arsenal to offer them?
- for ongoing retainer contracts, how to determine the amount of time a client requires per week/month/whatever
- how to address this issue to the client during the spec/pricing process
- how to address the issue of major releases (moving from 5 to 6 is potentially very time consuming, for example)
- how to present the client with the idea that modules are constantly going out of date, and what the benefits of constant updating are
Any thoughts?
Good points - should we start a google group or something?
It sounds like you're talking mostly ab maintenance contract.
In my mind the retainer agreement for me would be mostly new development but of course could include maintenance, that's just up to the client.
I would just indicate the level of difficulty and time for updating modules and the core, especially for major release updates such as 5 to 6. For normal upgrades you still have issues as far as how many sites run off of that one install, how critical are those sites, how critical is the module being updated, how much time etc. I update our multi-site install often for our lynxmark sites, but we're only hosting ab half a dozen and so it's not that big of a deal but if you're hosting dozens of sites, sometimes module updates can have big implications. You would need to do extensive testing, so in that case it just depends on how the client views the benefit gained in those updates.
Now for migrating from 5 to 6 I wouldn't recommend doing that in bulk, I would move one site over at a time and even then only when there's good reason to do so. That takes a lot of time and effort per site so I would only do that when say 6 has a lot of new features that the client feels is worth the money to upgrade.
I wouldn't try to "push" constant updating of sites bc each update could potential cause instability, so I would recommend security updates as high priority, otherwise it's case by case basis in my mind.
Move this elsewhere?
Perhaps now would be a good time to push for a Drupal "Business Issues" group on g.d.o or something?
It seems to me that there are quite a few things that need ironing out where Drupal is a "little but different" from the rest of the crowd. Namely, this issue, hosting, the rate of development, etc...
Thoughts?
Sounds good
Start 'er up
Go for it
I'll join! Kind of related - is there any kind of "rating" system for Drupal developers (would we even want one?) - I mean, something like elance - www.elance.com - worth checking out if you don't know it - allows clients to rate providers. This strikes me as a generally good thing, although can cause problems for new providers starting up, as even if they are able to provide high quality service, they don't have ratings to prove it.
Ok
I'll have a word with some of the "right people" tomorrow and suggest this. It might be off topic enough that it's not accepted, but personally I feel it has some merit, so I'll give it a shot.
here's the deal
With any of those, be it from guru or elance or anywhere is that people learn how to game the system and figure out a way to get bogus reviews + earnings to catapult them to the top. Probably the same companies that spam you with bids so that they're bidding on every project and thus those rating systems lose credibility. I think it's one of those things where there's not a perfect rating system so for companies they just have to do their research the old fashion way, references, portfolio, resume, etc to determine who's a good candidate and then keep the ones that pan out.
ratings
Yeah, rating systems are tricky. It only takes one disgruntled client to damage a provider's reputation.
I think clients should only be able to offer positive recommendations. It's like the old saying goes, "If you have nothing nice to say, don't say anything at all."
At the competition of the project, the client is presented with a form that states something like, "The project was completed to my satisfaction. I would recommend this provider to others." with an "Agree" and "Disagree" button. The response is recorded, but only affirmative responses show in the provider's recommendation count. Assuming the client clicks "Agree", the form could also include a checkbox with the text, "I am happy to serve as a reference for this provider." A provider who continually provides poor service will fail to accumulate recommendations and references.
Just a thought...
Agreed, any ratings system would need to be carefully designed
Agree with both the above - a ratings system is only valuable if it shows genuine information - but that's a design and implementation problem, I think there could be a lot of value in a proper ratings system.
Another system I know allows you to rate the rating! i.e. when you get a rating, it says "Is this rating fair/unfair?" etc. I'm not sure how it then processes that result. This would leaves the door open for you to say that all good ratings are fair and any bad ratings are unfair, so my guess is that it does not affect your own rating but maybe affects others. Perhaps our collective brains could design a functional ratings system - there are existing modules of course but too simplistic for this I think.
Just off the top of my head:-
ClientA rates ProviderA giving a good rating. (10/10)
ClientB rates ProviderA giving a bad rating. (0/10)
--> ProviderA now has an average rating of 10/20.
ClientB also rates ProviderB giving a bad rating, but ProviderB says this is "unfair" -- this has *no* affect on ProviderB's own rating, but reduces the "weight" of the bad rating for ProviderA from 0/10 to 0/5.... Thus ProviderA now has a better rating of 10/15 instead of 10/20. Ok, it's still open to abuse - the two Providers could be the same person, or two people collaborating etc. But I think if the whole thing is relatively small (not a huge system like elance) it could work well.
... um, on the other hand, maybe that's just too much - a simple comments system where clients say "thanks for the great work" etc, might be better, and new clients can read through the comments.
Rating *clients* can be valuable (do they pay on time, do they keep changing the spec, are they reasonable when unforeseeable difficulties crop up...)
Maybe a "referral" system? - In other areas of work that I'm involved with, I'm forever being asked "do I know anybody else (who's available)".
Much of this assumes a many-to-many relationship of clients to providers, which is probably not the case here. So I've concluded I'm talking gibberish.. I'll shut up now :)
Reader beware
On the internet, as well as elsewhere, anybody can say whatever they want to, making truth hard to discern. I hope the human race is able to adapt to this, or else we're done for. I haven't installed fivestar or other rating modules, but I hope that they're capable of only accepting one rating per user, with the latest overwriting the old. This capability, plus the capability of deleting users, is probably the best we can hope for. And yes, let people comment to explain their rating.
Um...
Are we adequately off topic now, people? :)
Personally I'm always off-topic
Are we off topic or was the topic the wrong one in the first place? No need to answer, I'll shut up now :)
Ya we are off topic
I like testimonials myself, I've been getting into the habit of asking clients for testimonials if they are pleased with my service =)
Already is one
http://groups.drupal.org/consulting
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
Ah!
Reliable as ever, Michelle. What would we do without you? :)
Interesting, I signed up
I'm new to the whole organic groups thing - I see a bunch of jobs posted but where do you find the discussions?
.
@NikLP - Awww
@jaykali - Start one. I think there's a lot of jobs posted because that fits under the subject of "consultants and business". But it doesn't mean it has to be all jobs. Just create a new discussion and there you go.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
I started one up
Not sure how it will do. I only see topics on that main page, seems like they will get lost after a while. I don't see a central place there to look at all discussions.
The Big Guys will always include an ongoing element
Maybe worth remembering, anybody big (IBM, Oracle, etc, etc) would always include ongoing fees in any significant project. Maintenance, support, upgrades, security auditing, etc. The majority if not all medium-sized providers will do the same. So why any difference just because you're a one-man band? This is in answer to how to convince the client as to why pay for ongoing aspects - basically because is has to be that way.
Another way forward, if you can handle the cash-flow implications, is to have *everything* bundled into an ongoing fee. By this I mean *no* separate set up, design, development charges - you create whatever it is that they want, and they pay $x per month for using it, *forever*, and that of course includes support, updates, etc. This assumes that you control the server where its all running, otherwise they could just take a copy of the system and do a runner. This approach won't work for everybody nor all projects, but to a business client it should be an attractive alternative. In some cases, it also allows a company to avoid budget restrictions, e.g. they can't spend $5000 but they can spend $500 per month.
I used the above approach very successfully in my own software house (it was around for thirteen years and employed more than 15 people) - we produced a type of CRM system - it could either be "bought" (anything from $10k to $50k) plus ongoing support/maintenance fees or "rented" - a single monthly fee with everything included. The second option was very popular. You have to get the price right of course!
Aye
Yeah I agree that this is an option, certainly for some people. Of course, in order to make this work, there has to be a minimum contract span, which inevitably works out more expensive in the long run (ie the length of the contract). Then you have to convince the client to keep paying after the fact. This is a darn site more simple if you are providing a "service" rather than "goods" - a website could essentially be viewed as a one-off item. I personally think that's a stupid way to look at it, but that's what I'm seeing in the SME marketplace.
I have to say tho, If I could muster a service based business together I'd probably be doing exactly the above...
"there has to be a minimum contract span"
For "safety" as the provider, maybe yes. But actually we had minimum contract period. The thinking went like this:
* Does this client need what we have? (a genuine business need.)
* Do we have the best solution, or at least one of the best solutions?
* Are we dealing with the right person?
If we believed that we could answer "yes" to all three, we went ahead. The risk, in reality was minimal because we had a great product. The fact that there was no minimum contract period made it much easier for the client to say "yes". Once they were using our system they were pretty much "locked-in" -> ongoing income.
Ya I tend to agree
Of course it's up to each developer to decide how they want to do business but with my retainer concept I would most likely not require a minimum contract span for businesses that set up direct deposit.
Under my plan I would, however, require a 3 month pre-payment of the retainer if the business does not do direct deposit. This is the main reason why. Dave Ramsey, financial guru, says that a collections problem is a sales problem. Unfortunately there are clients who won't pay so in my mind the best way to insure payment is to set up direct deposit which to me solidifies a bit the idea that you'll probably get paid on time, if the direct deposit doesn't go through you suspend service until the account is up to date. What I like also ab direct deposit is that it implies an ongoing relationship which I like.
With the pre-payment option for businesses that don't want to do direct deposit that is a way for the developer to be sure he/she gets paid if they aren't on direct deposit.
In my experience doing freelance contracts where you get paid in increments or when the site goes live usually lead to delays in payment. If it's your livelihood then I think having an agreed upon payment system makes a lot more sense.
This is not for newcomers. I think new freelancers are left with whatever they can get. For those of us with a bit more experience and a solid portfolio and resume, I think there's more room for better contracts.
To me the arrangement of the retainer can be enticing for clients because it a) insures availability for X amount of time b) is a discounted rate for those hours c) establishes an ongoing relationship so that they can count on you as a resource and d) with my plan doesn't require a long commitment.
One last note on rates, I personally like simple so my rate would be just a flat rate whether it be for new development, support, installs, etc. - I think for consultants it makes sense not to over-complicate rates because doing so can look contrived.
Also a good place for drupal jobs
I may be late to this party but the google groups jobs portion of the site seems to be the ideal place for finding work freelance or otherwise:
http://groups.drupal.org/jobs
So if that's obvious I apologize, but I've been looking everywhere for good leads and this is the best place I've found.
And to find freelancers
Facebook Drupal Service Providers Group http://www.facebook.com/group.php?gid=2449272488&ref=ts.
Nice
I joined