Fixed Price Projects

A lot of people hold the belief that a fixed price project is the only way to go.  Clients looking to have a project done think that it ensures their project will cost an amount that they are willing to spend on it and, an hourly basis project can very easily get out of control and end up costing considerably more.  

Developers who take on fixed price projects do so for a variety of reasons; some figure it’s the easiest way for them to get work, especially when times are tough and others are uncomfortable with negotiating and having to keep going back to the client for more money.

Where I stand on this is that I do NOT take on fixed price projects; they are bad for me, and they are ESPECIALLY BAD for the clients.

After that last statement, you are probably thinking that I am completely insane.  How can a fixed price project be bad for the client?  They know exactly how much they are going to spend so there are no surprises there, and that’s the most important thing, isn’t it?  No, it is absolutely not the most important thing.  The most important thing is that the job gets done properly and actually works.

So let’s take a step back and look at the two different scenarios that come into play, on a fixed price project, and see who loses out in each situation.


The developer underbids the job in order to get it and, at some point in the process, he realizes that he really didn’t think this thing through all the way and he is now working for a very small amount per hour with no end in sight.  At this point, it is human nature to lose interest and, if another project comes along that pays better, the original project gets pushed to the bottom of the pile and this keeps happening until one of the two parties dies, or the client decides to cut his losses and start again.  In this scenario, BOTH the client and the developer lose.  The client doesn’t get what he paid for and the developer hasn’t made enough money to either do a good job or see it through.


The developer overbids the job substantially.  He knows that he probably isn’t going to get the job anyway but, just in case he does, he wants to make sure that there is more than enough money in it to allow for changes in specifications, etc.

In this scenario, the developer does very well indeed and the client loses because they paid TOO MUCH for the work.

Since in both of these scenarios, the only person who might come out on top, is the developer who overbid the job, let’s look at the alternative.


This is where the developer gives the client an estimate on a range of hours that the job is going to take.  That range is based on the specifications provided by the client and by the developer’s experience in doing similar types of projects.   The developer keeps a close track on the hours that are being used; any changes to specifications are discussed and the client advised of the possible time increases to get those items done.  The project stays on track and gets done in a timely manner.

In this scenario, the client only pays for the time that is actually being spent on his project so he ends up paying a fair price for the work.  The developer is motivated throughout as he’s is getting paid what he thinks he is worth (which he probably is) and so both parties end up winning.

Leave a Reply

Subscribe To Our FileMaker Tips & Tricks

Join our mailing list to receive the latest FileMaker tips, tricks and video how tos from Michael Rocharde

You have Successfully Subscribed!

Subscribe To Our
Video Posts

Join our mailing list to receive info on new videos as we post them

You have Successfully Subscribed!

Website Apps