| When buying custom software development you | | | | can put all of their time into coding your project |
| have two choices on how the project will be bid; | | | | rather than logging their hours. |
| Hourly or by the project. So what are the pros and | | | | The problems with per project bids |
| cons for both choices as a consumer? And which one | | | | 1. It takes research time to create an accurate |
| is the right decision for you? | | | | quote. Depending on the size of the project, it can |
| I'm not going to spend too much time on hourly | | | | take 100 hours just creating an accurate bid. |
| projects because they are fairly self explanatory. 10 | | | | Someone has to pay for that research. |
| seconds into a phone call with a software vendor | | | | 2. Once you agree on a price, the programmers job |
| and you should have the hourly rate. It's a simple | | | | becomes getting the project done with the least |
| number. However, the problem with hourly projects is | | | | amount of work in order to maximize returns. |
| that you're at the mercy of the programmer. If your | | | | 3. Fixed bid projects mean that you're going to pay |
| told it's about 100 hours of work then that number | | | | for the worst case scenario. If a company is going to |
| really has no legitimacy. After you have paid for 100 | | | | issue a fixed bid price and assume the risk then they |
| hours of labor and you find that the project is only | | | | are going to pad the price - after all they don't want |
| halfway completed, then you have no recourse. This | | | | to come out at a loss on a project. So with a fixed |
| is particularly a problem with overseas companies | | | | bid price that means that your always paying for the |
| whose only competitive advantage is low cost. It | | | | worst case scenario. |
| becomes a price war to be the lowest bidder. | | | | So as a buyer, what is the smart solution for me? |
| What we are really debating here is risk and who is | | | | The per project bid guarantees you that you have a |
| going to assume it. When a project runs long, | | | | ceiling on what your going to spend. You will sign a |
| someone has to pay for it. In an hourly project, the | | | | contract and it will encompass everything that your |
| buyer is assuming that risk. With a fixed price, the | | | | project is going to include. If the project goes long, |
| programmer is assuming the risk. With software | | | | that's not your problem. With a fixed bid contract, |
| development projects there is inherently huge risk | | | | you can begin to trust your programmer as now |
| with every project. | | | | they are your advocate in getting this project done |
| The arguments for per project bids. | | | | as quickly as possible. And you have that contract to |
| 1. There is a cap on what you're going to spend. | | | | fall back on in the event the company you hire starts |
| Theoretically there will not be any surprises. | | | | trying to extort additional dollars from you (assuming |
| 2. There is never a "meter running." Your not making | | | | that the laws of your country apply to the |
| an investment decision every time you communicate | | | | programmer which is not the case with offshore |
| with your programmer. You won't have to ask | | | | software development). |
| questions like, "is this issue worth a $100 phone call?" | | | | One other suggestion is before committing to a |
| 3. If the programmer finds additional work within the | | | | programmer, google them. If they have been around |
| scope that was unanticipated but must be | | | | for a while there will be some feedback on them - |
| performed, they can do it without having to come to | | | | either good or bad. If there is not any feedback then |
| you for additional funds. In those instances, additional | | | | you're still stuck relying on your gut instinct. I can't tell |
| work would otherwise be viewed as an attempt to | | | | you how many potentially bad situations we have |
| generate additional billable hours. | | | | avoided just by Googling companies before we |
| 4. This is the most uncomplicated way to work | | | | started doing business with them. |
| together. From the programmers perspective, they | | | | |