I've been playing with a lot of different commercialization models, but something that interests me is whether other people are "billing for bugs".

Let's say you write a custom system on either a fixed bid or an hourly basis. After completing the project, the client notices two things:

The first is something that clearly doesn't work correctly as per the agreed, written spec. It was clear in the mock ups that a feature should do x and it just doesn't.

The second is a reasonable edge case that lessens business value - you don't have a validation that the user is over 13 when you save their details and that is a problem (although that problem had never been discussed before).

If you work on an hourly basis, is the additional work also hourly until you're done? What happens if the client is out of budget? Do you usually do the work as goodwill and if so, what's your threshold - 1% of the billable hours? 3%? 5%?

If you provided a fixed bid, I'm guessing that you'd fix the first issue. What about the second?

Input appreciated. I have my own set of answers (which I'll post later), but I'd love to see what everyone else has to say!

For all of those solo/small business consultants . . . what percentage of your time do you consistently find to be billable? Once you take out conferences, blogging, learning, setting up your computer, sales activities, keeping an eye on the accounts, doing year end taxes, being involved with mailing lists, reading about new trends in software engineering, figuring out Ant, re-installing Eclipse, getting MySQL working properly on your laptop and all of the other stuff that comes up, what would you say your steady state billable range is? 50% of your "at work" hours? 40%?

I'd be interested to know what you assume, what you find (if you have any detailed records) and what multiple of your planned hourly salary you charge to cover non-billable time.

I've found it very interesting that on an XP list recently there's been quite a lot of talk about fixed price for features which at first seemed to me the antithesis of the Agile approach. At the same time, we've been developing fixed price software for years, but I'm wondering if a blended model might be the ideal solution . . .

[More]