I'm completely on board with the "bill by the day, not the hour" idea. Having implemented it in our own consultancy, it's done wonders.

But it hasn't gotten us to the stage you're talking about - we're definitely making headway in establishing ourselves as (Python) experts, but I don't think we're really at the stage where we can sell based solely on the customer's value - building software is simply too replaceable a commodity (See note). Nor do I think we necessarily want to be there - lawyers don't sell on value, after all, nor do most professional services firms.

Also, increasing the billing increment too much and selling based on value starts taking you into "fixed-project pricing" territory, which is a whole different field. Not that it's better or worse, just different, with its own set of needs. This we discovered in retrospect after practically switching all our work to fixed-pricing, then realizing what a big difference that was (that we weren't equipped to handle).

Note: Building software is too replaceable in the sense that there are plenty of alternatives to get some software built (hiring, cheaper freelancers, etc). We certainly manage to sell ourselves as better than alternatives because of speed an expertise. But that's a far cry from building projects and selling on value, which IMO is again, a whole other field which is hard to shift into from any old software consultancy (different customers, different sales pitch, different needs). I mention this because tptacek's basic point of "switch to daily billing" is better advice in that sense - it's easy to do from just about any position with just about any set of clients, and by magic improves your life.

Yep, that's exactly what I'm trying to say. Thanks!

What I would suggest though is to bill by the day and find a way to measure what you have delivered against changes to a business goal

This is the next step after bill-by-day/week - linking your work to something they care about - using evidence collected by software.

To be fair this works even as an employee, a permie / contractor or a actual, gone next week contractor.

What didn't you like with fixed price billing?

The problem with fixed price work is you create a conflict of interests from the start. It's in your interest to do as little as possible for the price and it's in your customers interest to get as much as possible for the price.

That and all the issues of requirements gathering up front.

Isn't it also true that hourly or daily billing creates a conflict of interests from the start, because it's in the customer's interests for you to finish as fast as possible and in your interests to finish as slowly as possible?

Yes, but those are smaller than the converse, where the conversation is about whether something ambiguous/new is in or out of scope (strictly adversarial discussion), rather than whether such ambiguous items are worth it or not to the client (simply a resource allocation discussion).

I have a hard time believing that the potential conflict of interest situation that emerges from a fixed-price engagement, where the customer ultimately can accept or reject the work, would be worse than the elemental conflict of interest that emerges from hourly billing, where customers have little control or even insight into hours billed.

It's not about likes and dislikes, both are workeable systems. But they're very different. Some obvious and not so obvious ways:

1. The obvious way - in one you get paid no matter what, and your entire job is to keep the customer happy enough with you that they'll happily continue paying you. With fixed-price, you have a "semi-conflict-of-interests" as others mentioned.

2. These different incentives cause a lot more work up-front for requirement gathering, a lot more work on contracts that are well specified, etc. Btw, that also means billing at much, much higher margins to cover the uncertainty.

3. Not so obvious - doing fixed-price projects requires a lot of focus around managing multiple projects at the same time. When managing X employees on multiple projects, this gets tricky. Why? Because fixed-price projects tend to have lots of waiting: build some infrastructure, wait for design, build and deliver first milestone, wait for feedback, deliver final project, wait for bugs, fix bugs, wait for final confirmation.

So you're basically learning to juggle multiple projects at the same time. And all projects have points where their schedules shift - I've had clients who are completely desperate to get things off the ground, where I would've put 90% chance of their e.g. graphical designs being ready for us, who suddenly had business emergencies that required them to slow down. This happens ALL THE TIME, as does the converse (10 designs arrive at the same time and now you have 10 clients waiting eagerly for updates).

4. Another non-obvious difference - the kind of clients you can take on tend to be very different for these two methods. You'll tend to get more non-technical clients looking to work project-based, and more technical clients looking for time and material, especially when what you are doing is augmenting their own technical staff with expert knowledge.

To summarise, each style of billing or more correctly each type of project you can take on has its own challenges, they're not better/worse, they're just different.

Very good points. I would add that one's relationship with customers is much more unpleasant when doing project pricing. The "out-of-scope" discussions are difficult and can make collaboration strained.

Why is hour < day < week? I read the patio article where he said that, but since I've never been a contractor, I don't understand the difference that would make.

Also, since an hourly rate is standard and job postings say how much they pay by the hour, isn't it common to be rejected when you ask for a daily/weekly rate?

Thomas has explained this in more detail, but:

+ The minimum billing increment switching to 8x your 40x your previous increment will, by itself, scare away the worst pathological clients in the pool. (If you have a $50 hourly rate, some clients might naively assume that they can get meaningful software development done in 3 hours. Where's my website? I've paid for three whole hours. What do you mean you're still setting up the dev environment?)

+ If you bill hourly, you have to account for your time in fractions of an hour. This will lead to more overhead (spend 17 minutes on a phone call? Record that fact somewhere! Maybe dicker over whether it's really .25 hours or .5 hours and whether this totally inconsequential $12 difference matters to the client.), more stress from your client reviewing your work on a minute-to-minute basis, and more friction about clients misunderstanding the nature of knowledge work. I can't just slam keys for 8 hours straight, and you wouldn't want me to do that if I could.

+ [I'll add something here in a moment but Ruriko wants breakfast.]

Good clients don't care about you charging daily/weekly. I never lost a client over it. I'm the professional, my standard practice for doing my thing is the standard way for working with me. If you can't deal with that, that's fine, there are other people out there. (Relatedly, I never, not even once, got a contract from a "job posting.")

Quite. Leads to a ridiculous micro-management frame!

1. You aren't billing for time - you are billing for a deliverable that will be done during the day / week (or part thereof) billed.

2. This is not the same as contracting for BigCorp on a 6 month java position at 600 usd pday. That's close but basically an employee without benefits

3. If you move from 100 dollars an hour to 4000 dollars a week (8000 seems to be more norm - you won't work every week) then the high price is to get then to focus on deliverables and not think o you as a person on a seat for six months but as someone who proved the last project did well

Too many reasons to re-list. You can use the search bar on the bottom of the page to find me talking about this ad nauseam.

We've never been rejected for a client for not billing hourly.