I made a lot of mistakes when I first started freelancing.
Firstly, I didn’t know how to charge for my time. I calculated how much money I thought I should make in a year, divided it by 2000, and set that as my hourly rate. If it’s not already clear, this is not the way to do it.
Your hourly rate must also account for overhead (i.e. sales, documentation, follow-up) and down-time (the time in between sales). Not to mention client emails, invoice preparation, managerial oversight of contractors. There’s a lot that goes in to running a business that’s not billable time – your billable rate still needs to somehow cover paying for that time, though.
Second, I presented itemized project proposals that broke every task down by hour. So many hours for initial design. So many hours to build-out a prototype. So many rounds of feedback and revisions. So many hours for additional unit testing.
Fact: Clients don’t care about hours, they just want to know how much the project will cost and when it will be done.
It’s All Relative
I’ve been both on the developer side and the client side of these arrangements. The first thing a client will do when you quote both your hourly rate and the number of hours you expect a project to take is figure out how much per month they’re paying you versus their in-house team. They’ll then take the time to figure out how much effort per month you’re putting in on the project versus their team and, sometimes, fire back with this request:
Can’t you assign some additional developers to make things move a bit faster?
Your clients don’t care how many other projects you’re working on or how burned out your team might be. They care about their project, the delivery date, and its impact on their business.
Once upon a time, I quoted a project for a client in Germany who really wanted to move things along quickly. The full quote came to about 1,000 hours, and I expected it would take three developers three months to complete everything. I lined up my subcontractors and got ready to kick things off. Then came the inevitable call:
But we really need this to launch next month. Can’t you just hire more developers to get things done more quickly?
I was inexperienced enough I almost said yes, before a tech-savvy team member in their conference room cut in:
Leave the guy alone. We knew this was a big project when we hired him; adding developers probably won’t help. Remember, nine women can’t produce a baby in one month.
He didn’t know it at the time, but he was very right. We managed to cut the project down to 2 months by hiring an extra contractor and working several hours of impromptu overtime.[ref]Again, in my inexperience I agreed to the accelerated schedule and extra developer without raising the contracted rate.[/ref] When all was said and done, I barely broke even after paying my subcontractors. It was a heavy lesson to learn, and one I won’t ever repeat.
Your Time is Your Time
The other hours-related horror story I tell is related to a client doing the math on my estimate and timeline. They ran some numbers and (correctly) figured out I would only be spending 8 hours per week on their project.
I was working full-time at another employer and was freelancing primarily in the late afternoon or on infrequent vacation days I took exclusively to get some head’s-down time on external projects. My client didn’t care; they were attempting to in-source me as their development team and expected a certain amount of exclusive availability and timeliness in production.
To satisfy them, I ended up bumping up the project ship date and hiring yet another contractor to work 30+ hours each week on the account. The project got done according to my client’s expectations – but because I was paying a subcontractor, my total cut of the project fee was in the red.
Yes, I lost money trying to meet my client’s expectations.
The ironic thing was the client knew absolutely nothing about web development. Until they saw my itemized hours report, their management had been perfectly happy with both the schedule and the overall budget – it was knowing they weren’t buying my time exclusively that forced my hand with expediting the project.
Stories, Morals, and More
In short, I learned a great deal from these experiences.
Firstly, I learned that when a project’s schedule gets tighter, the total fee must also get higher. Yes, it’s nice to get things done more quickly for clients, but we quote a certain budget and timetable for a reason. Move one element and others must move as well. Otherwise it means you’re lying about your capability with one of the elements in the first place.
Second, I learned to respect both my clients’ expectations of time and my own schedule. Yes, they expect things to be done in a timely manner, but I also have to weigh in my own (and my team’s) schedule when booking things out. No one lines to work overtime – and no one likes to pay for exclusive attention and only get a few hours of attention each week.
Most of all, I learned to not quote hours to clients. Quoting hours does present a certain amount of transparency from my end – everyone knows exactly what they’re getting. But it also prompts the client to second-guess and micromanage my schedule.
Can you hire more staff to get things done more quickly? Sometimes, but only if I also increase the cost to cover added expenses. Also this won’t apply to every component of the project.
Can you just work harder to get the project done faster? Sometimes, but with the same restrictions as the above question.
Can you drop unit testing (or some other development quality feature) to get the budget down a bit? Yes, but this means our potential QA budget will have to go up as well.
There are tradeoffs at every component, just as there are with any negotiation. But the one thing that will always put you in a bad spot when it comes time to make those negotiations is needlessly exposing internal information – projected hours – to a client without the insight or background to understand what the numbers mean or why they’re set a specific way.