| That's an interesting take on the reason to bill hourly, and I know a lot of developers who do that. Personally I've switched to mainly doing fixed-bid contracts. Rather than selling my time, a fixed-bid contract allows me to sell my expertise -- and that often is more lucrative. For example, a client may need a solution to putting hundreds of documents online and making them searchable. That may only be 40 hours of work, but it's a problem that has been costing the client tens of thousands of dollars in lost productivity each year. As an expert, I can sell them a solution to their problem in a way that saves them money and is still profitable for me. Beyond that, a well-written fixed bid contract lets everyone know exactly what the costs and expectations are, and what the schedule is. No more having projects drag on and conflicting with other projects I need to be focusing on when we all know that there's a set deadline for the delivery of a specific solution. Of course, doing this successfully requires knowing what questions to ask to get a detailed spec, understanding how long it'll take you to really do something, and anticipating the gray areas. I also like to build in "flex time" into fixed-bid contracts. For instance, I might specify that the contract includes "20 hours of revisions" to the requirements once the client has had a chance to review the prototype. I'll price this into the estimate. This way the client knows they'll have a chance to make changes, but they also know there's a limit after which the project cost increases. |
I noticed that small businesses who want fixed-bid contracts tend to be cheapskates and they're the type of person who'll haggle every little detail and look for an excuse to refuse to pay.
I'd rather target the higher end of the market than the bottom of the barrel. Also, the work I prefer tends to have greater complexity than just churning out a simple site quickly, making fixed-bid less sensible.