You're not a Lawyer or a Mechanic The nature of the arrangement is more similar that not. Both do project based work as service professionals. And both have un

You're not a Lawyer or a Mechanic The nature of the arrangement is more similar that not. Both do project based work as service professionals. And both have unforeseen variables that cannot be known at the time of estimating. Lawyers routinely deal with unforeseen political issue (ruling not going the way they expected) and mechanics routinely deal with unforeseen problems that are technical in nature (mechanical failure, that was not known until the heads where pulled off). Software developers routinely deal with both natures of unforeseen variables in addition to the client adding work after the estimate. Which would be akin to a mechanic giving someone a quote and then when they are half way through the project the client saying well while you are in there go ahead and change out the pistons for forged steel ones, and then arguing because the client got charged for the parts and labor. In all three cases the client pays for the additional work not the service provider. paying by the hour is a poor and dated way to do business I differ on that opinion as well Sitepoint does too, almost all of the top talent in any development field works by the hour not by the project. Most know to not take the entrepreneurial risk of another company while engaging in a contract that limits their reward. http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing-vs-hourly-billing/ http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing-vs-h... You're selling a software solution to a client, so you should charge for that solution Right and if I am shouldering the risk of the development costs, I am going to license it to that company as well as there competitors. If they own the result of my labor then they pay for that labor. building software isn't an exact science and many projects overrun. and that is not the developers burden to bear. Scope creep is a reality with any novice firm who is looking for software development. A fixed bid set up an adversarial relationship immediately. You will constantly be parroting "out of scope" to the point that the client will be just as pissed as they would have been about cost overruns as they are about not getting the product they want. The knife cuts both ways, and the reality is more fixed bid projects fail, because at a certain point of losses the developer walks or the software gets shelved because the project as scoped is not what the client thought they wanted at the time of developing a functional specification. That's a fantastic way not to get hired for a project. It's really not, I educate my clients on the risks of software development and what they can do to limit scope creep, changes in priorities and politics, the three big killers of projects. Further all of my clients now are big tech firms, so they are well versus in these realities. Not allowing myself to into a bad deal in no way affects my ability to get projects. Coming off as an amateur in contract negotiations can hurt far more than being firm on how you structure your work. because you're the expert and you'll have the better idea of how long it should take. Unless you are a politician, there is no way that you can do this with any accuracy, the client will creep scope, it is a given, with time and materials you have a lever that you can pull to say OK we can add it, but it is going to affect you budget by X and your delivery by Y. It puts the onus on them to control scope creep, if it is on you, you will be strong armed into accepting it. If you don't they are just as mad as cost overruns and you have received no money, so when they pull the plug you are the one left holding the bag. I have been doing this for 20 years and have seen first hand that fixed bids cause more problems for both sides. Take a look at all the top guys on HN, take a look at there stories as to why they only do time and materials, each and every one of them will have a fixed big horror story.