A developer friend of mine, Tian Davis, posted a little commentary about Five Skills Every Freelancer Must Have. He based his comments on his experience as a developer and on a talk given my Nathaniel Talbott some time ago. See Tian’s post for a summary and an embedded video.
I agree with most of Nathaniel’s points, and they’re ones most freelancers don’t do well (i.e. taking every project/client they can get, not collecting promptly, failing to deliver value continually). There’s one point I don’t agree about, though, and it’s the one Tian expounded upon in his post. Tian, I hope you don’t mind me respectfully disagreeing, and I’ll tell you why I disagree.
I run a small full-service interactive agency with offerings from design & development to social media, PR and reputation management, so I wouldn’t consider myself a freelancer. The same principals apply, though, to small agencies and freelancers.
What is Valuable?
I don’t think I agree with #1 in Tian’s summary, which comes up around 50:47 in the video. Time & Materials pricing benefits the young developer or the developer who doesn’t manage scope well (which is very hard to do, I will admit). It ensures you get paid for the time you put in. I would argue that based on Nathaniel’s other points, a developer should be paid based upon the value delivered, not upon the time put in.
Healthy Inflation
As I have grown more and more experienced and efficient with my work over the years, my hourly rate has increased significantly from the $10/hour where I started back in high school. But there’s a point–probably around $150/hour–when the hourly rate becomes an obstacle just because of how the number looks and feels to a client. If you’re a young/inexperienced freelance developer and you charge $50/hour for your work, that looks like a good price to most clients. Once you’re at $100/hour, you’ll discourage some clients, but it will give you a higher perceived value among other clients who will pay for your expertise. At $150/hour, you had better be an expert. If you have the portfolio and client recommendations to back up that rate, you should still be able to find plenty of work, but there will be a large portion of the market that chokes on the $150 and won’t even consider hiring you.
I have no problem with potential clients who don’t want to pay what I charge–I don’t care to haggle over whether I’m worth what I charge, and I’m not offended when someone isn’t interested in paying (unless I find out after the work is done!). I seek win-win client relationships, as Nathaniel recommends, and it’s not win-win if a client thinks I’m over-charging or if I think the client is under-valuing my work.
The catch, from my perspective, is that some senior developers are far more than 3 times as efficient as most $50/hour junior developers.
Consider this Scenario
Let’s say that a task that would take most junior developers 5 hours to do, you can do in 1 hour because you’ve done it several times before and know exactly how it should be done right the first time. On a Time & Materials contract, that puts you at $250/hour (as compared to a $50/hr junior developer). How many clients do you think you’ll find who wouldn’t walk away when you tell them your rate is $250/hour and you want to be paid hourly for the work?
On the other hand, if a junior developer quotes $2500 for a project (estimated at 50 hours of work), and you quote $2500 for a project (10 hours of work), you’re on even ground. Because of the high quality of your work and your proven track record, though, you should get the contract every time. Why would you hire a junior developer for the exact same price as a senior developer?
Of course that’s based on the assumption that your senior developer will be more efficient than your junior developer, which isn’t always the case. I know there are some things I just can’t do any more efficiently than the next guy (i.e. data entry, basic HTML, etc.). Some developers have a knack for understanding your business and figuring out what are the right and wrong things to do, which can save you a lot of time and trouble. Experience gives a developer lots of examples of best and worst practices. That’s frequently far more important and valuable than saving you a few development hours here and there.
Can’t we all just get along?
One way to mitigate risk for both the client and the developer is to do a scoping phase up-front so that both parties know exactly what you’re getting into before the actual implementation begins. I have done this with several clients, and I’ve been told they love the outcome. The scoping phase is usually about 10% of the cost of the project, and as a deliverable, I provide a detailed specification for the website that the client could use as a Request for Proposals with other developers if they wish. By the end of the scoping phase, if I haven’t thoroughly impressed the client, I always encourage them to seek other proposals on the project. So far, I haven’t lost a project after completing the scoping phase, and I always do the projects on a fixed-fee basis after the scoping phase.
While I usually only propose a scoping phase for medium-to-large projects ($10,000+), the same model could easily be applied to small projects (i.e. $2,000). A specification for your site for only $200 would be a bargain, and it would be a great opportunity to get to know the developer before committing to the full project.
Who’s with me?
I would like to hear some success and failure stories from the developer community and business owners. Have you had more success with time & materials (hourly) projects or fixed-scope/fixed-price projects? I’m open to different perspectives on this, so please weigh in!
