One of the critical choices in accepting a project is whether you will bill based on a fixed or hourly basis.  The bottom line is that one approach places more risk on you as a provider.  The other puts it on the customer.  At least, that is the typical thought.  However, you can adjust a fixed bid or how the hourly rate is paid to shift risk around.

Fixed or Hourly as a Project Approach

I think that this is a decision that should be considered far more from the basis of how the project will go as opposed to finances.  A fixed bid will make it far more likely that a customer will want to squeeze all they can into the project.  On the other hand, the provider will try to keep it as thin as possible.  That does not mean both parties are greedy or unfair.  They are just going to focus on more or fewer features depending on where they sit.  Even worse, a fixed bid can lead to a large number of hours spent on nailing down change requests and what should be included as part of the original definition.  That is overhead that does not serve anyone.  It may be me, but I find less haggling is a path to less stress.

Finding Fairness

There is not one approach that will be more intrinsically fair as pricing goes.  The key to that always comes down to what is billed and what is not.  There are arguments around pricing for bug fixes.  However, you cannot be fair in that discussion without accepting that they do occur.  That leaves it up to the provider to bill for hours worked and include bug fixes or not.  If they do not bill for bug fixes, then the standard rate will need to go up.  They are effectively being paid for their time.  Thus, legitimate uses of time (including testing and bug fixing) need to be addressed.  It may sound good to have an agreement where bug fixes or support will be free but that time will likely be covered in a higher general rate.

Rather than try to solve fairness and budget concerns through fixed or hourly pricing, it is better to focus on requirements and estimates.  A project that is well designed and defined will be easier to estimate in terms of hours worked, time elapsed, and total cost.  At the end of the day, that is the goal of everyone involved.

Learn more in the book written for Develpreneurs at any stage in their progress:  https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

 

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply