Skip to content

Comment on Poll: As a freelancer, how much do you bill per hour?parent

Comments

If you bill daily, you don't have to charge half when that happens.

A daily bill rate aligns your incentives with your clients. Instead of scrounging for hours to bill, you estimate how long things are going to take, and get a premium for getting things done quickly. Everybody wins.

Maybe I don't understand the idea of a daily rate.

I thought it meant that I price my time in 8-hour increments. Which means that if I have to leave early, and put in a 4-hour day, then I only charge them for half of that.

Are you saying that if I bill daily, then I can charge for a full day even when I work only half a day?

I'm all in favor of finding a formula that removes the impression that I'm trying to gouge clients, or that I'm taking advantage of the blank-check aspect of hourly billing.

Of course, at the end of the day, it all comes down to trust. Fortunately, in almost all cases, my clients learn that they can trust me to be aligned with their business interests, and that I'd rather help them to succeed than find new ways to charge them without working. However, if there's a way for me to profit more while simultaneously increasing their trust (or reducing the time it takes to build such trust), then I'm all in favor.

Your interests are not aligned with your clients when you bill hourly. It is in your interests to work slowly, spreading the work over as many hours as possible. It is against your interests to invest in time-saving techniques and tools, because they will ultimately reduce your take-home pay.

What you do is, quote your client an estimated time to completion for your project in (in order of preference) weeks, days, (or only if required) hours. You have a minimum increment, which could be a week, or could be a day, but shouldn't be an hour.

Then you get the work done as quickly as possible and charge your client using that minimum increment.

First of all, I do genuinely try to use the fastest and best techniques that I can. Maybe I'm subconsciously doing things slowly, or not using the best techniques I can, but I do think that I try to do the best and fastest job that I can. My interest is in pleasing clients and doing new and interesting things. Taking a long time on one problem is bad on both fronts.

But yes, I can very easily see how someone could take advantage of hourly billing.

As for how weekly billing works, I'm afraid that I didn't understand your example. It sounds like I estimate a project as taking two weeks (i.e., 10 days). One week into the project, it looks like it'll take one more week than I originally expected (i.e., a total of three weeks). So I tell the client that it'll now cost them for three weeks of my time. Did I understand you right? And if so, how is this a win?

This isn't complicated.

You do a proposal for a client. You give an honest conservative estimate of how much time it's going to take.

Say it's a Rails CRUD app with no special domain code. Ok, 2 weeks, broken out into 2 billable weeks. The proposal says something like:

   Week 1: 5 person/days, $5,000 (Setup, Discovery, Backend)
   Week 2: 5 person/days, $5,000 (Front-end, testing, delivery)
   TOTAL PRICE: $10,000
Accompanying your proposal is a SOW that says something to the effect of:

This project will be billed on a time/materials basis, starting Monday January 23rd and continuing for 10 contiguous business days through February 3rd. If additional time is required to complete this project, it will be billed at a rate of $1,000 per person day, provided that notice is provided within 1 week of February 3rd.

Presto, a proposal for a project that costs $10,000 billed time/materials at $1k/day (again, lowball figs).

Now, 2 weeks to complete this project is conservative. Also built into every proposal, whether you like it or not, is the collection of moments in every working day where you are not productive. So ask yourself, if I took 100 provigils† and eliminated ALL NON PRODUCTIVE TIME from my schedule for the entire next 2 weeks and completed this project in 7 days instead of 10, who should get that $3,000 of value I just generated?

The answer to that question is "you".

You don't generally want to rig your contracts so that they are padded out with unproductive time the client pays for; that's called "rustproofing" and it's bad business. But at the same time, clients actually value determinism more than they value any single billable day. If the client accepts a project for $10,000, they are going to be way more irritated if the project takes 15 days to finish than they are if you finish in 9 days instead of 10.

You have knobs to turn here too. Say you finish in 9 days instead of 10 because you drug yourself into working 18 hour days. Keep the $1,000. Say instead you finish in 5 days instead of 10 because the project turns out to be way simpler than you expected. Well, in that case, give the client their $5,000 billable week back. Think of this in terms of a minimum billable increment, where you don't credit partial weeks --- if you had to work at all in that week, that week is shot for other clients --- but will credit full weeks.

You see now how it's maybe not in your best interests to have your minimum billable increment be "one hour"?

Please don't do drugs.

OK, I gotta say that after many years of consulting, this is the first truly new, clever billing technique that I've seen. Better yet, it's a win for all sides.

This comes closer to per-project pricing from the client's perspective, which they prefer because they want to know how much they're paying. (As you put it, "deterministic pricing.")

I tend to time-slice my weeks, so I don't think that it would work for me. But it might well work for the people who work for me, who do tend to work complete weeks on projects.

I do have to wonder how Israeli companies would react to this sort of thing. My guess is that they'll do the math, and then complain about the high hourly rate.

But the only way to find out is to try, and you've definitely inspired me to give this system a whirl. Thanks so much for sharing.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.