This is a great post, an unusually great one on this subject, and I only have this to add: don't charge hourly. You can break your finances down by the hour if you want, but your customer should interface with you on a day-rate basis, or, if you're ambitious, a week-rate.
I'm not sure I've ever talked to someone who moved from hourly to daily and regretted doing so.
I agree in general, but I think it depends on the kind of work you're doing.
Right now I'm doing some actual consulting (in contrast to contract work), and being available by the hour has been helpful. I turn up at a couple of regular meetings; when some issue comes up that I can help with, I help.
On a day rate, the expense is large enough that people only want to call you in when there's something they perceive as big and serious. But when it's just time worked, they're happy to grab you for a short chat. Which often turns into something larger. And it makes it easy to leave the contract open; I've been doing this with one client for circa 6 months. That has let me influence them a lot more than a short burst of days would have done.
My problem is that if I charge daily I feel obliged to work at least 8 hours a day, which frankly I often don't manage. Some days I waste too much time on the internet which I don't want to bill, or I am too tired (unfortunately my sleep is unreliable).
It's a bit lame, I'd like to be a better person who can just do a normal 8 hour day, but so far I have always failed. One reason I like freelancing is because I can only charge for the hours I actually work. It's also a major reason employment is not for me.
There is no such obligation; in fact, disposing of that obligation is part of the point of billing daily instead of hourly. Think about it this way: when you bill hourly, not every second of that hour is spent in diligent work either.
I'll try that next time, must admit I really have to overcome some inner resistance.
I've been thinking to try "project based pay" again for that reason (fixed price for delivery/milestones), but that is of course fraught with other problems. Most importantly the dependence on other people that can delay execution and therefore also payment. And of course the difficulty of making good estimates.
As someone who is just starting out freelancing, and constantly hears 'bill daily, not hourly', how does that work when daily work hours aren't uniformly distributed? Some days I might work 5 -6 hours, others I may work 12. I like the flexibility of being able to work when I want and would hate to have to compromise on that.
If you put in five or six hours of focused, high-quality work in a day (i.e. not spending most of it attending meetings, checking your e-mail, rearranging icons on your desktop or whatever), you're doing about as much as can be sustainably done; charge for that day with a clear conscience.
If you spend a couple of hours trying to concentrate before realizing you didn't really get anything done, you're just messing around and you need a break, take the day off and don't charge for it.
As znowi mentioned, don't bother charging hourly or daily or any period of time.
The client will ask for a specific thing to be done. Give the client a specific price for that thing. That's it.
How you calculate that is your business. Personally, I figure out the worst-case scenario and price it for that. If I finish earlier, because of my brilliance, well we can just call that profit.
You're happy because you just finished something high quality and in good time. The client is thrilled because they knew what they were going to pay, got what they wanted, and got it quickly and professionally. The client didn't have to worry about hourly rates or daily rates, unexpected surprises, etc. they knew what they were going to pay. You took the risk out of the transaction for the client and made a good amount of cash for yourself. Everybody wins.
I like project-based billing but a lot of people don't, because it exposes them to risk (scope changes, unexpected complexities, client downtime) that they can avoid with time & materials billing. A weekly rate is, to a customer, pretty close to the same interface as a project rate, so if you're thinking about charging project rates, consider weeklies instead.
Also remember that part of the idea of upping your billing increment is not accepting piecemeal work.
I'm interested to know how you manage the risk inherent in project-based billing.
In my experience it is simply unworkable: the client will provide the vaguest of specifications and providing them with a set-in-stone price raises unrealistic expectations. The requirements are simply too fuzzy at the outset of a project to be able to price it accurately.
Of course the solution only becomes more concrete as the project progresses and requirements change and crystallize based on feedback. This is expected behaviour of course, but I've never been able to reconcile it with project-based billing.
Do you simply allow a certain buffer zone and take the good with the bad?
I'll just quote myself: "Personally, I figure out the worst-case scenario and price it for that."
Experience helps with the above. Obviously you can never know precisely how much effort something will take. Stuff comes up. Even if the work itself is stupid easy, it might take you 2 hours to find the exact line of code that needs to be changed and sometimes it takes 5 minutes. And you never know which is which. So charge for 2 hours.
> the client will provide the vaguest of specifications and providing them with a set-in-stone price raises unrealistic expectations.
Clearly define the parameters of the project. Clearly define what you will do. Don't do any more or any less than that.
If the client needs something extra done, and this happens, simply price that out separately.
> The requirements are simply too fuzzy at the outset of a project to be able to price it accurately.
I agree. Experience and clearly defined parameters and contract goes a long way in project based billing. If requirements are fuzzy then we developers need to help the client to make them clear by asking the right questions.
Look, I am a developer from India. An above average developer by Indian Standards, but the problem is most Indian clients are also below an average client. They dont know what exactly they want. This ends up increasing number of iterations, which is ok. But then I have never experienced a client appreciating these iterations.
There are significant cultural differences between how business is done in the West and in India. I talked about this in another comment.
I don't want to give you advice one way or another, because I'm not Indian, so anything I would say is bullshit. Talk to some developers in India who aren't just above average, but are in fact, stellar. Some of them are probably making good money. Ask them what they do, they'll be able to give you the best advice for the Indian market.
You can still bill quarter days (it is really hard to do anything meaningful in less than 2 hours). Billing by the day just gives you more flexibility when the client asks for a discount. Giving a $100 discount on an $800 day sounds bigger than a $20 discount on $100/hour.
I see this advice over and over again, but I'm really interested in reasoning behind it.
Hourly rate works fine for situations where one day you work 3 hours, and another day - 9 hours. The day-rate by default assumes that you at least work for 8 hours. So why bring this unnecessary constraint?
Some reasoning for switching away from hourly billing:
- Less time spent tracking hours
- Less risk of client quibbling about time spent on each task
- Disassociation from hourly rates (e.g. a large client may pay $20K a week for an important project, whereas people may balk at a $500-1000 equivalent hourly rate)
- More likelihood of working on larger, more important projects (less risk of the project falling apart, not getting paid, etc)
A daily rate will limit your client pool, but in a good way: bigger, more serious, and richer companies. A weekly rate will do this even more-so. But if you can reach the big fish and convince them of your value, more lucrative.
I see. It makes sense for short-term-ish projects.
But I had experience of long-term working with the client, where there are no milestones. There is just an unlimited continuous flow of work to be done. So if you charge daily, that most likely implies 8 hours of work per day. Basically, it is more like a regular employment, but with a freedom of working whatever hours you want, including zero.
I was just summing up the worked hours at the end of the month and billed with it.
The hours you work are largely irrelevant though. Your services are of high enough value to the customer to warrant charging per day. If you can provide the agreed upon service within 2 hours rather than 8, good for you. It doesn't matter to the client as long as they get what they pay for.
It of course depends on the work you do and so forth. If you are contracted by day for a job that require 8 hours of availability time, then you should probably work those 8 hours.
I think I see what you're getting at, but this seems like a circular argument. Yes, if the client is paying you "per day" and leaving it up to you to define a day, then of course they always technically getting what they paid for. Seems like if you really want to be paid based on output, you should negotiate a project rate. How else does it work? Do you and the client have to agree each day on the deliverables for that day?
I'm not sure I've ever talked to someone who moved from hourly to daily and regretted doing so.