Preface: This article was written mostly half a year ago, as I was wrapping up an intense period of freelancing and sub-contracting. It is less relevant for me now, as I'm now an equal partner in a small web firm and my freelancing days are beyond me - however, I thought it might be a good read.
How much are you worth
As a freelancer and sub-contractor, one of the basic skills I had to develop is conveying value to prospective clients. In order to earn the rates I want to charge, it's important to make the client understand the value he is getting in return.
Clients seeking freelancers are often looking for cheaper rates, as the thinking goes that companies inherently charge more - companies have additional costs that freelancers do not, and those costs are reflected in their rates.
While looking for cheaper rates, clients still expect quality - and those two properties have a very tangible relationship. You can assume higher rates reflect greater quality - however, in software development, quality is an attribute that is hard to explain to non-technical people, and as in every other occupation, higher rates don't necessarily mean higher quality.
My goal when communicating with a prospective client is to convey to him what is the value that I bring to the table. While admittedly my rates are not cheap - I believe they are more than fair, and the value I can give greatly exceeds the monetary compensation I demand for it.
So how can I convince a client that I'm worth what I ask for?
Talking about quality in software development
The following are metrics that are widely accepted as proponents of software quality:
- Maintainability - How easy is it to debug and maintain the source code? How is it to make small changes?
The cost of maintaining the product over any stretch of time is highly dependent on this. Also, larger development projects will bog down during active development if they are not maintainable.
- Extendability - How easy is it to add functionality and features to the product? This affects the cost of future development, cost that may be larger than the original investment.
- Security - How secure is the product against known and unknown exploits in its domain? This concerns mostly products with online accessibility, which places web products at the highest risk spectrum.
- Domain relevance - How well does the product actually answers the problems it sets to solve? this is a metric that is hard to measure without real users testing the product. However, having plenty of experience in this area can definitely reduce the margin of error.
And another metric that is not software-development specific:
- Professionalism - How much respect does a service provider has for his line of work? how much respect does he have for his clients and how much does he put into his communications with them? how good is he with meeting time schedules and price estimates?
There are many ways in which I try to convey the value I can give in each of those areas -
- By presenting my best work in online profiles with a short summary of the what I reviewed above. (Warning - links are in Hebrew :) )
- By writing in my blog about issues relevant to those qualities.
- By actively participating in forums and other software development communities.
- By always trying to be transparent and professional in any communication with clients.
The fact that I perform those activities because I enjoy and learn from them is to my advantage. :)
Those activities are mostly behind the scenes though, cause the next most important step is:
Striving for a face-to-face meeting
My number one goal is to meet clients face-to-face. By putting a face behind the CV and answering any questions in a professional manner, I increase the chances of a closing a deal tenfold.
I know many freelance developers have a reluctance to meet face-to-face, and are generally shy in such meetings. For the most part I embrace it - I strongly believe that after such a meeting the client will know exactly what value I stand for, and then it will only come down to costs versus value considerations.
Another equally important aspect of the face-to-face meeting is to understand in greater detail the scope and features of the project. Often, a second meeting for specifications only is required. I will write about the specification process in a future article, hopefully.
Creating a transparent and fair cost and scope proposal
When creating the actual price proposal it's important to keep two things in mind:
- Be clear on what's included in the proposal
- Make it obvious how much every part costs separately
Being clear on what's included in the proposal is a no-brainer. It will prevent future misunderstandings and points of contention. To a large degree, this is also influenced by the level of specifications document attached to the proposal (you do have one, don't you?).
Making it obvious how much every part costs is an effective way to translate to a client how much effort will it take to develop specific features. This allows a client to make value considerations - how much a feature is worth to the project versus how much it will cost to develop it, and often allows for compromises that can take a price proposal from the "out of range" zone to the "let's do business" zone.
Allow the client to make his own decisions regarding what features to keep or leave out, but provide your opinion as well. We, as web professionals, have a responsibility of educating our clients with our knowledge and experience in the field. Don't be afraid to influence the client with what you think is best for the project.
Stand behind your pricing
This might be difficult advice in those times of economic strife, however I strongly recommend standing firm beyond your price proposals if you believe them to be fair and thought out. If you represent with conviction that the price proposal stands for your worth, it increases your integrity in the eyes of the client.
Never leave money you believe you are worth on the table. There are other ways to come to terms that all sides can live with, such as trimming down on features and scope or converting some of the cost into shares in the project.
I remember that when I wrote this piece I had just submitted a price proposal for a freelance project at the sum of around 4,000$US. I was pretty sure I had conveyed my value perfectly to the client, though he had argued that the price is unacceptable for him. He wanted to close it at 2,500$, which is a pretty steep cut.
I was caught in a serious dillemma - I was out of the market for a couple of months, living off previous projects income, and it was the height of the financial crisis. Should I take the hit and take the project anyway or stick with my pricing?
I decided to hold firm to my pricing. The client went off to request more price proposals from other developers (with my specifications document - which at the time I was not charging for), but continued to contact me in 2-3 weeks interval, asking whether I'd be willing to come closer to his terms.
In the mean time I started my own web company with two other extremely talented partners, and we went on to close several major projects that make that 4000$ seem a bit disproportional right now. I was recently contacted for a last time by that client, and I was happy to respond that I'm no longer available for his project.
My own moral of this story is that if you follow through with your beliefs and represent your value well, you will eventually get through to the right clients. Clients that refuse to recognise that they need to pay for the quality they want to recieve, are clients that I rather not work with.