I don't have good citations for these figures, but I'm pulling this out of Stephen Fishman's book "Working for Yourself." In one informal survey of self-employ

I don't have good citations for these figures, but I'm pulling this out of Stephen Fishman's book "Working for Yourself." In one informal survey of self-employed people it was found those who charged fixed fees earned on average 150% more than those who charged by the hour for the same services. In another survey by a trade journal it found that self-employed people who charged a fixed fee earned 95% more than similar people who charged by the hour. I believe these surveys were across industries and not specific to software. Make that what you will, but it seems to suggest on average you're much better off charging a flat fee. I can conjecture a few reasons why. 1) If you're good enough to have the confidence to charge a fixed-fee, you can estimate based on the normal hourly rate and add a healthy amount of contingency. Because your estimates will be accurate you will almost always come out ahead compared to going with a straight hourly rate. 2) Customers are willing to pay a premium for cost certainty even if that cost ends up being higher. 3) By putting a cap on the cost of a project, the developer is less likely or unable to exploit that so the project may actually get completed faster and more efficiently than if a payment ceiling wasn't over his head. Controlling a fixed price project is difficult and simple at the same time. It's difficult because it's so easy to hang yourself if you're not careful. It's easy because all you need to do is define the scope ahead of time and agree up front that the price and time needs to be adjusted when the scope changes. So whenever the client asks for something outside your mutual understanding of scope you have a provision in the contract that states you must amend the contract for the difference in cost and development time. It's called change control, and can be as simple as "hey, that feature is way beyond what we agreed upon. I can do it but it will cost an extra $4,000 and the delivery date needs to get pushed back two weeks. Sign this contract amendment to that affect if you still want me to do it." Likewise, if something that was assumed in the contract turns out to be untrue, that can be revisited with a contract change. For example, assume there is an open source library for barcode scanning. If it later turns out there isn't one suitable for the task, you're completely within the contract to say, "Hey, I know we were hoping to save some time and money by using this library. But we agreed it was a risk and after I used it more it has too many issues and this endangers the success of the project. We can buy this commercial package for $4,000 but I will need to redo a lot of my work. I'll give you a break on my labor, but it will still cost $6,000 and add another week if you agree to it." Something like that.