Context " />

Freelancing Tips via Rails Camp 4


The fourth Australian Rails Camp happened back in the middle of November - and it was unsurprisingly and extremely enjoyably awesome, just like the previous four. Ryan and Anthony did a sterling job with putting it all together.

I probably talked a bit too much - I certainly felt I had more than my fair share of peoples’ focus - and while I rabbited on about Sphinx and Ginger, the topic I really enjoyed ranting about was freelancing, because it became far less about me, and far more about sharing the wealth of everybody’s experiences. I provided a few starting points, and then wise RORO minds added their own thoughts and opinions.

I can’t reproduce all that here, though. I wouldn’t do it justice. What I can do is go over the same notes I had then, and you can add your 2 cents (or five dollars) in the comments.

Freelancing Maths

One of the first things you need to be aware of, when you start freelancing, is how much to charge. I didn’t have a clue, but some more business-minded friends put me on the right track, so I’m sharing their advice here - don’t give me any credit for it.

So, let’s assume you want to start freelancing, and you have a target of earning $80,000 over the year (yes, some of you may say that’s too low, but others will say it’s too high - it’s just an example, okay?). You can use this as a basis for figuring out an hourly rate. There’s 52 weeks in a year, 5 days in a week, and 8 hours in a day…

 52 weeks
x 5  days
x 8 hours
x ?  rate

But wait a second - are you really going to work all of those 52 weeks? I doubt it. You’ll need time off for annual leave, sick leave and public holidays - the times when an employer would still pay you when you’re not slaving away. Australian annual leave is four weeks, sick leave is usually two, let’s add in another one for public holidays, and that brings us down to 45.

 45 weeks
x 5  days
x 8 hours
x ?  rate

What are the odds you’re going to have work all the time though, and are you really going to have eight billable hours each day? Unless you’re some sort of machine, the answer’s no, trust me. So lets drop eight down to six.

     45 weeks
x     5  days
x     6 hours
x 59.25  rate

One thing we’ve missed in our calculations is superannuation. Again, using Australia as the example (because it’s all I can reliably comment on), you’re supposed to be putting away 9% of your income into your super account. Let’s factor that in:

     45 weeks
x     5  days
x     6 hours
x 64.59  rate

Okay, so we can get an hourly rate of about $65 from that maths. And that could be fine… but maybe you’ve been eyeing off RailsConf or RubyConf or other such events. They’re not cheap - and hopefully employers would normally fork out the cash to get you there. You’re the employer now, so how are you going to afford it? Add an allowance into your calculations.

Again, due to the remoteness of Australia, it’s extra expensive to get to any of the major Ruby conferences. If we assume you’ll get to two of them (again, could be extravagant for some of you, but this is all hypothetical), then I’m adding a touch over $12,000 - flights, hotels, insurance, the conference tickets - to bring us to a nice round $100,000 target.

Also, I’ve dropped the number of weeks down another two - it’s not like you’ll be getting anything done for your clients as you jet around.

     43 weeks
x     5  days
x     6 hours
x 77.52  rate

Okay, our final hourly rate is about $77.50.

I know a lot of the more experienced developers are looking at that value and thinking it’s pretty low - and going by market rates (for Ruby developers), it’s definitely below average. Some say a good ballpark figure for a decent Rails developer is $100/hour - USD or AUD (remember when the two currencies were almost on par?). This doesn’t mean you should charge that much (or that little) - but it should factor into your thinking.

All that said, you need to be comfortable with what you’re billing your time at, but don’t be afraid to charge what you’re worth. If the idea of having more cash than you expect scares you, there’s plenty of charities who would like to be your friend. Or, you could just work less, and spend the extra time on cool things (and they don’t even have to involve code!)

Freelancing Profile

Knowing what to charge is useful, but it’s not going to bring in the clients. Being known will help that problem, though - and there’s a few things you can do to help that.


Interpret how you will - a normal blog, twitter, tumblelog, even gists and pasties - sharing your ideas and knowledge is a great way to get your name known to others. It also helps build some human connections, via comments, emails or directed tweets. If it is valuable, they will find you (and if you think they need help, use a site like RubyFlow or RubyCorner to bring in some eyeballs).


If there’s a neat bit of code you’ve found, library you’ve come across (or written), or knowledge you think is valuable to others, offer to talk about it! It can be at your local Ruby group, or at something like a Rails Camp or BarCamp, or if you’re really comfortable up on stage, think about applying for a RailsConf or RubyConf slot.

I’m not a natural public speaker - but my confidence has grown in leaps and bounds from giving talks to fellow developers. Granted, I need to build up a bigger repertoire of topics, but I’m a bit less nervous about standing up and announcing my thoughts and opinions to others. It all started with an email from Tim Lucas asking what I was going to talk about at the first Rails Camp - and now Rails Camp folks are probably sick of hearing my voice.

They know who I am, though, and they know what code I’ve written. And that’s led to a referral or two for Rails work (usually Sphinx-related).


Networking is a dirty word - and I can see how building connections with others for the purpose of connections, instead of meeting cool people, is a bit dirty. The much more fun alternative is to socialise - go out to social events, find those drinks happening in the evenings of conferences, have a conversation with a person you’ve not met before at your local Ruby meet.

Down the track, you will find these people may throw work your way - or maybe you’ll just learn cool new ways to code, or share some of your own knowledge, or make a good friend. All chalked up as wins in my book.

Release Code

Releasing your own code - from snippets to plug ins to full-blown applications - is a great way to show peers that you know what you’re talking about. It also shows potential clients that too, and reaffirms that you’re worth the rate you’re charging, and that you can be creative.

In my own case, I’ve done the occasional bit of Sphinx consulting due to my work on Thinking Sphinx.

Coincidentally, doing all these things are rewarding in and of themselves. I don’t do them to bring in work, I do them because they’re fun and I meet awesome people, which is (I think) the best approach. The opportunities they lead to are just an added bonus.

Your Turn

So, what’s your advice to a budding freelancer? Is there anything here that’s a bit Ruby or developer-centric? Any more general suggestions to keep in mind?

Also, please keep in mind I’m not an expert. I think the above advice is useful, but it is just advice. There’s no hard and fast rules that should be followed.

And the name of this blog has nothing to do with my work lifestyle, but the idea of deities who freelance for each other. Don’t take it as an indication of my ego. Honest.

Piotr Sarnacki left a comment on 30 Dec, 2008:

One of my advice would be: never ever take projects with hour rate less then you normally want to have.

How do you count hours needed for the project? I had some projects, when real work hours number was much greater than what I’ve expected… It’s hardest part of project for me. If you say too much client will go somewhere else, if you say too low you will end up with extra not billable hours.

Another fact is that programmers (especially beginners) will often underestimate the time needed for project…

Justin French left a comment on 30 Dec, 2008:

Awesome post. One thing I think you’ve overlooked (I certainly know I did for a while when freelancing) was the overhead of quotes/proposals/estimates.

I ended up factoring in a few hours a week for that too. Some jobs required nothing more than a handshake, others required a bit of upfront work that wasn’t really billable to anyone but myself.

pat left a comment on 30 Dec, 2008:

Piotr: Good point re: rates.

I’m almost always involved in an hour-by-hour basis - rarely do I have to estimate upfront (occasionally by feature, but that’s about it), so I don’t have much experience there.

Indeed, I’ve only been freelancing for two years now, so it’s not like I have loads of experience generally.

Justin: you’re right. I also forgot to allow money and time to manage finances - either figuring out GST yourself. And I’m sure in other fields there’s other time overheads I’ve not factored in.

Olimpiu Metiu left a comment on 2 Jan, 2009:

Excellent advice. I would add getting published (outside your blog) as another solid way of getting recognition and leading to referrals.
Writing a book is definitely not for everyone but there are more accessible avenues including Peepcode mini-books or (shameless plug) the excellent upcoming Rails Magazine.

John Yerhot left a comment on 2 Jan, 2009:

@Piotr Sarnacki
I pretty much just assume that however long I think a project will take, it will actually take 25% longer.

Good write up!

Apostlion left a comment on 3 Jan, 2009:

@John Yerhot
Someone used a rule of “double the estimate, add 10%, and double the estimate again”. While quite, er, extreme, it’s remarkably true of quite a few projects, especially large ones, especially when an external team is involved—feature creep, scope creep, HR creep all take quite a hard hit on estimating prowess.

John Chapman left a comment on 3 Jan, 2009:


One way I deal with this is to charge for estimates but refund the amount if the project goes ahead; it puts an end to the time wasters who don’t have serious intent, and it deals fairly with those who want a good proposal/estimate before making a decision and therefore should be willing to pay for the skill and time involved in producing such a proposal. And if they then decide to go ahead with contract with you then they get a credit so it’s good for them and good for you (since you got the contract you wanted).

Of course this only works if the time is a few hours to a few days - if it’s a significantly more complex proposal then the time just has to be charged for upfront and not credited even if they do go ahead with your services.

Ricky Cox left a comment on 3 Jan, 2009:

Such a shame about the aussie dollar taking a nose dive recently. I hope that scrambles out of the gutter soon.

You might also need to factor in expenses such as hardware, software updates, office expenses, accountant and rental fees.

Regarding quotes, I personally don’t do “fixed bid quotes”, or accept jobs that require them. You can usually negotiate on this, unless it’s an industry savy client that wants to squeeze you to maximize their own profits and you’re best to steer clear of those “bottom of the barrel” types clients.

The quote is only an estimate as outlined in the terms and conditions submitted with the bid. The actual amount can vary significantly, depending a number of factors, such as scope creep, which isn’t necessarily a bad thing if you’re working closely with a client.

Steve Hopkins left a comment on 4 Jan, 2009:

Hi everyone,

I’m not really a freelancer, but more of a consultant contracted to different companies for extended periods of time. A handy rule to use for such longer periods of time is the rule of 3rds.

Most consultants split their revenue 3 ways. Profit, Expenses and Salary. Believe me, when you get started you think the hourly rate will suffice really well. “Wow! You think…100k in a year!” Cash flow, invoicing issues and many other little problems (largely) always seems to spring up. As such, you could probably safely assume that your 100k is actually delivering you any useful wage somewhere closer to 40k. Increase your wage 30% to cover for these sorts of things. (Thus, Expenses + Profit)

If you’re freelancing business is going really well, and the only way to get through the great work is to bring someone else on begin charging 33% more again (salary) to pay for someone else to come on board.

I know that’s a little more “how to build your business” rather than Freelance advice, but I found it really useful. This is the environment you are playing in - don’t forget how talented you are and realise that for all the work you do there is an established consulting house doing the same stuff for triple the price.

Finally, once you have your rate, you should spin it into a day-rate + a half-day rate. Don’t get caught going to see a client for 1 hour, and losing travel time and half a day from your schedule. Block your time. If the client wants to see you, go there for the half day or day. And if they only need you for an hour, still charge for the half-day. We all know those 10am meetings kill productivity like nothing else.

Great post Pat, and great conversation!

Dan Newman left a comment on 4 Jan, 2009:

Agree with much of what’s been said - excellent knowledge share.

Fixed Bids: These can be fine if a very clear spec is in place. Sometimes a new client wants this because they don’t know you yet, and are reticent to have you billing hourly and piling up costs without making sufficient progress. With a fixed bid, assume that there will, even with a good spec, be some extra work involved that is unspec’d … so I always add ~30% time on. The nice thing about a fixed bid is that 30% …if all goes well you may end up getting more for the project than the hourly. That’s risk/reward of fixed bids. But I never would do one where there’s a fuzzy unfinished spec.

Perspective: I think it’s really important to try to see yourself as a new client would. This is first and foremost the sum total of your web “presence”, and your resume. This is where a blog can add so much value… it’s a free zone for you to add spice, dimension to the impression someone is trying to get when considering you. A fully fledged LinkedIn profile is also very important. Get recommendations from key past associates, clients etc. As stated above comment on other blogs and get to know other consultants.

Ubiquity: keep a constant eye on job boards, and send resumes consistently, looking ahead several months. You may not get a gig but make a connection that comes in use later. There’s no cost to sending out your resume and blog url etc.

Perform Beyond the Call of Duty: The single best thing you can do for your hire-ability is do an better than excellent job on everything. The lion-share of work comes from repeats and referrals ..once that ball starts rolling along you can start turning down gigs and raising rates, as long as you deliver this level of quality and communication.

Derek Winter left a comment on 5 Jan, 2009:

I thought I’d throw in an idea about pricing options for development work.

I’ll also put up front that I’m not a freelancer; I come from one of those consultancy companies Steve refers to … although the chance to charge out at 3 x $77.52 per hour would be nice; I can’t say I’ve managed it yet :-(

Anyway, last year when looking into how best to structure commerical agreements for Agile Development work, I came across the idea of Target Priced Contracts.

The concept is that fixed price contracts mean the developer wears all the risk and therefore will need to add a buffer to mitigate the risk (ie. 30% on top, or the other multipliers described above).

Rather than take that approach, this method shares the risk between the client and the developer…

Once the work is scoped and an agreed set of deliverables defined, a price is set based on your reasonable estimate of durations (the target price, based on your daily rate). This price is signed off on by the customer. For the example, lets say 10 days, $750 per day, target price $7500.

During the project, rather than pay your full rate, they pay your ‘cost’ along the way. In our situation, thats the salary of the developer plus a little to cover overheads. For freelancers, its the rent plus enough to feed yourself and cover general expenses. (for the example, lets say $300 per day)

This will naturally leave a gap between what you’re paid and what the target price is (10 x $300 = $3,000 :- final payment is $4,500). If the contract finishes on time, then this is the amount the client pays you at the end and we’re all happy.

If you are outstanding and find faster ways of completing the work and finish ahead of time (say 8 days), the client still pays that amount. They’re happy because they paid less overall for the project (8 x 300 + 4,500 = $6,900) and you’re happy because you made the same amount of profit for less work ($4,500 for 8 days work instead of 10) and can get onto the next project

If however there is scope creep, things get tricky, something goes wrong and it takes longer than 10 days (say 12 days) then the client continues to pay your costs until you’re finished (an additional 2 x 300), but only pays the same final payment ($4,500).

So, they pay more (12 x 300 + 4,500 = 8,100) and your profit margin goes down (4,500 profit out of 8,100 total payment instead of 4,500 out of 7,500). So, you both feel some pain, but its not unfairly felt by either party.

This means that both parties are focussed on getting a good result - clear requirements, efficient delivery.

Its turned into a long post … sorry! Hopefully it fuels some idea’s and further thought for everyone though.

pat left a comment on 7 Jan, 2009:

Thanks all for the comments - really adds a lot more value to this post :)

Liam Morley left a comment on 9 Jan, 2009:

Good post! I’m pretty sure that a lot of freelance developers have already seen Freelance Switch’s rates calculator, but just in case, it’s similar to the above, but it does the math for you, and has a few extra items you may not have thought about.

This has helped me out personally.

Steve Crozier left a comment on 1 Sep, 2010:

Great post, many things to consider.

You may be aware of a completely different approach used by many consulting firms: the multiplier. For example, when I was running such a firm, we took the billable employee’s pay rate (say, $40/hour) and multiplied by 3 to get the billing rate ($120/hour). It is loosely rationalized as 1/3 for the employee, 1/3 for various other costs borne by the company (vacation, sick, bench time, etc.), and 1/3 for profit.

Multipliers range from about 2 to about 4.

Easy way to get a gut check.