Why I stopped billing hourly and you should too

If you're like most freelance developers, you bill by the hour. I want to show you why this isn't ideal, and suggest an alternative billing structure to simplify your relationships with your clients.

Imagine you have a client that wants to build a new application. The specification is vague enough that you know you can't offer a waterfall-style fixed-bid estimate. The project might rely on a third party, or might use technologies with which you're not particularly familiar.

In this case, you'd typically bill your client by the hour. This insulates you from risk because you know you'll be paid regardless of the value you deliver. And your client is happy because they know they're only paying you for the time you spend on their project.

But there are a few less-than-ideal things that happen in an hourly billing scenario:

  • Your client questions items on their invoice.
    Your invoice might say it took you 2 hours to "Refactor the XYZ module", but to your client, that doesn't translate into value for their business. Now you have to explain how and why you spent time on what you did because your client perceives them as unnecessary expenses instead of as part of the path toward producing value.

  • You cannot bill for time away from your desk.
    Raise your hand if you stop thinking about your work the moment you leave your desk! I'm sure your hand isn't raised. Mine sure isn't. We programmers spend most of our time thinking in one way or another about how we can improve our chops or solve our clients' problems. This is real time that goes unaccounted for in our billing when we bill by the hour.

  • You don't really bill accurately anyway.
    How many minutes in a given billable hour do you work? How many seconds? Are there moments where you're distracted? The truth is, no one can stay 100% on-task for a duration of time. Creative work especially is conducted in a manner that is sporadic and inconsistent. Billing hourly ignores this.

Is the answer to conduct a comprehensive estimate and then engage your client on a fixed-bid project basis? If your sort of work has predictable timelines and you're comfortable with the possibility of being underpaid, then a fixed-bid engagement might work. But for the rest of us building applications with vague timelines and requirements, fixed bid pricing is too risky.

Re-examining the problems with hourly billing above, there's a common cause among all of them: No one can deliver much value in one hour. So why do we use an hour as the default unit of billable value?

You feel undercompensated for all those minutes of work you inevitably spend away from your desk. Your client feels nickled and dimed for tasks that don't appear to contribute value to their business.

Wouldn't it be simpler to not have to think in terms of how many minutes or hours you spent working, and instead focus your attention on doing the work?

We've discussed how fixed-bid billing won't insulate us from risk. Instead of engaging on a fixed-bid basis, let's visit the hour's longer cousins: the day, the week, and the month.

Billing by the day results in the same sort of micromanaging relationship: If you spend an entire day doing a task which doesn't appear to have provided any real business value but does pave the way for the following day's work, it's difficult to effectively justify that cost to your client.

Billing monthly has the opposite problem: When your client receives the invoice, they're less likely to understand the value delivered relative to the fee they've paid. After a whole month, it's difficult to communicate effectively what was done and how it benefited them.

Weekly billing, though... weekly billing is gold:

  • You can invoice for value.
    In one week, you can deliver tangible value that you can qualify in a sentence on your invoice ("Delivered Feature X"). Your client will love this since the value you produce is what they care about anyway.

  • Your deliverables are clear.
    Each week, you can discuss with your client the deliverable you want to make the following week. This puts them in control and gives them a sense of what your fee is buying them.

  • It makes planning simple.
    Because your fee is fixed per week, it makes financial planning for both parties simple. Your client won't be surprised by your bill, and you won't be surprised by their expectations.

Hiring a web developer? Read this first

You're about to build a new web application, but you're terrified at the breadth of terminology and wary of consultants nickel-and-diming you.

My free book Why Software Projects Fail offers that framework. In this companion to your hiring and discovery process, you'll learn how to inform your next decisions and to empower yourself along the way.

In the book, you'll learn:

  • How to find and hire a trustworthy consultant
  • Why it's critical you pay for a software discovery
  • How to assess your consultant's bid
  • What to expect—and be wary of—during the development process
  • How to take control of your project

Enter your email address below and then click the "Send Me My Free Gift" button. I'll send you Why Software Projects Fail, and you'll be equipped for success on your next project.