Thanks for your reply. What I found useful whenever I could was setting rates per hour or per time unit (say, month) of development time, in large projects no o

Thanks for your reply. What I found useful whenever I could was setting rates per hour or per time unit (say, month) of development time, in large projects no one can really estimate how much time they will take to finish (for example, these days I'm developing some kind of 2.0 video streaming app for a client, and we're always testing it with people and adding features, thinking of new security measures and so on... we couldn't have written a full requirements doc at the start of this specific project). This protects your budget, but also your client's budget in the end (you don't need to do over-estimations for the costs to be safe). About parallel projects for products... I have none of them, but I use development work to learn more and more about difficult subjects that would take a long time of research or study to learn well (for example, on an older project I learned some basics of computer vision, etc). In the end that makes my development time more expensive and useful with every project. But maybe I should think in products too.