If You Bill by the Hour for Software, Charge What You’re Worth


The hardest challenge about being independent and freelancer in the software world is figuring out how to bill for your time.  What should your hourly rate be? Should you operate on project basis and fixed costs (please don’t)? Should you work as a partner with equity in exchange for doing the development work?


Over the last ten years I’ve operated under pretty much every kind of compensation model (that almost sounds dirty doesn’t it) that exists in the software world.  And I’ve come up with a few rules to live by if you’re on a similar path. 


Here are a few things you probably aren’t doing as a freelancer that I think you SHOULD be.  



You Are Not Accounting For All The Time/Hours Spent Not Writing Code   



A major mindset shift is that clients aren’t paying just for your time or code, they’re paying for access to your vast amount of experience and your mental capacity.


When you sit down with a timer and actually look at the amount of time you spend WRITING code, I mean really focused and typing and testing… it’s not really that much time.  


However the PROCESS of writing code, much like the process of writing anything else is a comprehensive thing that goes far behind the time your fingers spend on the keyboard. 


If you’re going to work as a contract engineer You need to account for all of the time spent mulling over issues, and sitting down to actually get stuff done.  



You Can’t Work on a Ton of Projects Effectively



I learned this one the hard way, because I lacked an understanding of what Paul Graham calls the Maker’s Schedule


Let’s say your average software developer works 50 hours a week.  Those 50 hours could be spent all on one project, or you could do 10 hours on 5 separate projects.  Simple math.


When I was first starting, I opted for the second option because I figured it was smart to diversify my work across several employers.  If one company went under, or changed priorities etc. then my income wouldn’t be as vulnerable.  


The problem with this logic is that I didn’t account for the Makers schedule or the cost of switching focus.


Every time you change projects or the problem you are thinking about, there is a mental commission that gets charged.  You lose momentum on the first thing, and expend more mental effort to get into the second thing.


Make sure you pick one or two projects to focus on intensely, and charge enough to enable you to do so.



Do NOT Accept Fixed Price Contracts


The main reason for this is because while pricing may be fixed, your scope and requirements NEVER are.


Most of the time it’s the fault of the clients for not knowing exactly what they need, this really sucks.


Some of the time it’s YOUR fault for underestimating the complexity of a project, this makes you want to jump off a cliff. 


There’s nothing more demoralizing than watching your ‘hourly rate’  diminish with each passing hour as you read over API documentation for the 17th time.


Easiest way to avoid this?  Just don’t offer fixed pricing on contracts. 



You Aren’t a Typist, Charge for Your Experience Too


Your experience as a developer has massive value for clients, and can not only assist in getting hired but also in how much you can charge. 


A business owner would almost always rather pay double to someone that has ‘done it before’ than save the cash on a junior engineer.   That’s why it’s important that when you sell yourself to a new client, you are leading with your experience and confidence in building a real world solution. 


This is the same in almost any other high end trade.  You don’t pay your plumber $100 for a 5 minute fix because swapping some PVC pipe is so difficult. You pay them for the last 2000 pipes he swapped to fix the same problem you are facing now.  The certainty has value, and he charges you for it.


In software, you should be doing the same, and you have the added bonus of the fact that most clients aren’t able to conceptualize the work you do. 



Start Thinking In Terms of Solutions – Their Business Case


We want to get away from being just a hired gun or service.  If you treat softwre development as a commodity the prices of your service will ultimately be driven down with increased competition.  If all developers are more or less the same and offering the same ‘commodity’ (an hour of developer time) then why wouldn’t your prospective clients pick the cheaper one?


We need to get away from this method of thinking.  The way to do it is to speak in solutions not in software. 


All freelancers tend to get too hyperfocused on their services, their hourly etc.  It’s not about YOU, it’s about the client and THEIR business.  


This is why it’s imperative you get some entrepreneurship and business savvy under your belt as soon as possible.  So that when you are talking with a client, it’s all about their business and the solution that would make them the most money, grow their brand etc.


By shifting the conversation away from the task at hand, you are subtly selling them not on your hours of dev time but on the actual real business RESULT.  Once the image of that result gets in their mind, it ultimately will get tied to YOU as the guy that can make it happen.


Now compare that to the other 10 developers your client spoke too that just talked about their 8 years of ‘experience’ and rattled off 16 buzzword technologies they’ve worked with.  


Who would you rather hire?  A generic ‘consultant’ or a guy that understands your business and wants to build something that’s going to help you grow and profit? 


Getting to the Next Level


A combination of the above is what helped me go from haggling over hourly rates to long running partnerships with companies on my own terms.  


If you want to have a more stable business consulting or freelancing, then it’s crucial you take steps away from a replaceable hourly commodity and move towards becoming a trusted and valuable partner in the business you work with.

Categories: Essays