[tcmb]

From a product management perspective, one nasty aspect of bugs is that it's impossible to estimate how long it's going to take to fix them. (Because when you've looked deeply enough to know that, the actual fix is often not much additional work).

So, an interesting proposition could be to hire you and pay you a fixed rate per bug fixed, instead of an hourly rate. My core team can continue working on features, and I hand you a backlog of 10 or 20 bugs that I then get fixed at a known cost.

You would then take on the risk of how long you have to work to earn that fixed rate, but on the long term it would probably even out for you as well.

[JamesBarney]

This is a terrible deal. A good rule of thumb is the person who understands/controls the risk best should take it on. And your team who understands the code base best and has fixed these types of bugs before would know far better how long they should take than a new contractor.

I don't think there is any industry where work like this wouldn't be time and materials.

[codingdave]

From a product management perspective, all bugs take 2 hours. Or 4. Or 8. But you just pick a number and roll with it. Because if you are looking at how bugs will impact a roadmap, then you can take them in aggregate and not give a hoot about one specific bug. Most bugs will be quick, and they will balance out with that one nasty one that takes a week. You do need to leave space in the project for bugs... so experiment a bit to find out how much space any specific team needs, and just know that much time will be spent on non-feature work.