Defnition of Fixed Price billing (Cost plus margin)

This I believe is the next favorite behind hourly billing. Typically a consultant will try to determine the features the customer is asking for, then determine a fixed cost based on their costs plus a margin of some kind. This generally includes considerations of time, travel, software tools, etc.

Note that there are other ways to determine a fixed price other than cost plus margin. This is only referring to fixing the price based on your estimated number of hours and the compensation you want per hour plus any additional costs like hiring other developers or purchasing software to do the job.

Pros:

• Simple to calculate for programmer and customer: (Hours * Rate + other costs) * 100% + margin% = Fixed Price
• Easy for customer to have immediate gut reaction based on their unconscious thoughts on what they want to pay.
• Programmer and customer don’t have to be concerned about renegotiating price.
• Pro for customer, all risk of overages placed on programmer.
• Programmer can present a price for the complete package instead of an hourly rate and number of hours. We are looking at the finished product instead of an estimated number of hours.
• The pricing and product are closely related vs. being obscured into hours and rates. This is easier to understand and requires no translation by either party.
• Since the pricing is set up front, the faster you can complete the project, the better it is for you as a developer.
• Same goes for the customer. The faster you get it done, the happier they will be. This dynamic is positive in that it incentivizes you to be more efficient unlike hourly billing.

Cons:

• Still depends on the programmer estimating their hours and being correct. This is unlikely. Especially on custom projects where each project is different with different challenges.
• Scope creep is a potential concern so is something you have to deal with up front. The developer will want no scope creep. The customer will not be able to define an exact product up front because they need to see something to understand how they will need to change it. Scope has to be defined on something other than features for this to work, like a business outcome. In some respects, this is actually a Pro.
• Programmer still may be thinking in terms of their hours and every additional hour worked will be seen as losing money, especially if the initial number of hours estimated is exceeded.
• In the same vein as hourly billing, there are a limited number of hours per day that can be worked. This tops you out at some number of maximum hours again. You can never work more hours in a week than actually exist. The only way to honestly increase your income then is by increasing your rate, or hiring more developers who will work at less than what you charge. This is a problem with charging any price based on the amount of hours you expect to put in.

For me: This is generally the way I work as I have not found customers to be ameniable to me actually charging for the hours I work after I exceed my original estimate. I am rather non-confrontational, so I have found the fixed cost approach to remove confrontations with the customer based on price. I have occasionally had issues with taking an excessive amount of hours to complete projects really killing my bottom line. This is not fun. But usually this was done because I made concessions when estimating and had a very price-conscious customer that I really should not have begun working with at all. If the customer is focused on getting the lowest possible cost, it is unlikely you will end up with a win/win solution.