Paying for Development: Hourly Rate vs. Fixed Cost
In my last blog post, I discussed how to choose a developer for your ecommerce project. In today's post, I'll discuss another important consideration before starting your project: whether to negotiate a fixed price contract or one based on time and materials. A fixed price contract means that you negotiate a specific flat fee to cover the cost of development and you will pay this amount regardless of how many hours it takes to complete the project. Time and materials means that you will pay an hourly rate for each hour worked on the project plus possible incidental expenses incurred with building your project (which are usually cleared with you ahead of time.)
Clients Love Fixed Price Contracts
Most clients are interested in a fixed price contract. Small business owners, in particular, are hesitant to spend money on development and they typically want to know exactly how much it's going to cost them before they start the project. This is a perfectly reasonable sentiment. Most people do not feel comfortable with an open-ended financial commitment.
Developers are like many other professions. Most developers are highly professional and skilled but there are some bad apples. If you end up hiring a developer that is less skilled, it may take he or she a lot more time than you expected to complete your task. With a fixed price contract, your project may be delivered late, but at least it's not going to cost you more money just because the developer was inefficient. There's also an incentive for the developer to finish the project quickly. There's no sense in dragging a project out if you're not going to be paid for the additional time.
Developers Hate Fixed Price Contracts
I've yet to meet a developer that enjoys working on fixed price contracts. Plenty of developers will agree to this type of contract, but that doesn't mean they like it. The first problem with this type of contract is that it requires a very precise estimate before accepting. The scope of work needs to be very detailed and every aspect of the work product must be understood before work can began. This poses a problem because a thoughtful evaluation of a project requires considerable time. Every time a developer fails to secure a fixed price contract, he or she has just wasted time that he or she could have spent servicing an actual client. If the developer does a quick estimate and misjudges something, then the result is a lower profit (or even worse a loss) for the project.
Time is Money. You Pay Either Way.
It might seem that fixed price contracts are a good deal for clients since they shift much of the risk to the developer. In my experience, this is not really the case. Developers need to be paid for their time and it only takes a few bad experiences with fixed price contracts before they learn how not get burned the next time. If you insist on a fixed price contract, you may have fewer developers to choose from because your project and budget constraints could be viewed as overly risky.
That might seem fine but, if you think about it, how does it work to your advantage to have fewer developers to choose from? Developers that decide to work for fixed price contracts are going to have to be very conservative with their estimates. They will need to build in plenty of "padding" so they don't get caught short. So you're not actually shifting the risk to the developers; they are sometimes countering this risk by inflating their estimates.
Let's suppose you are "lucky" enough to get an aggressive fixed price on your project. Perhaps you are working with a new developer who needs to build his or her client list or maybe you are taking advantage of a downturn in the economy. There is still a significant risk here. Let's say it's a $5,000 project and you've paid half up front. Fast forward to week number eight and the project is still grinding on. What's likely to happen next?
I'll tell you what happens - the developer will start to get resentful. Developers still need to get paid a fair wage for their work. You have a signed contract, so you're protected right? Wrong. Have you ever worked at a job where you were extremely dissatisfied? You may have showed-up for work on time, but was the company getting their money's worth? Hardly. So why would it be any different in the case of your developer? The developer will start to "sandbag" on you and look for any excuse to work on something ... anything ... other than your horrible money-losing project.
It may even get worse. Your developer might just quit on you. I've seen it happen more than once. People get sick of losing money and they just look for another line of work. You lose your deposit, they don't get paid for a huge chunk of work, and everyone loses. If they are professional and tough it out until the project is completed, don't be surprised to find that they are not answering their phone or email the next time you need an urgent bug fix or when you want some new features added.
Consider Time and Materials
My advice is to consider time and materials for your next ecommerce project. Many professionals (myself included) refuse to work on fixed price contracts. As a developer I find that hourly projects go much smoother because the client never wastes my time. It also forces developers to be conscious of their time usage. I know the client is not going to want to see a bunch of billable hours on some crazy idea I had.
But, in the end, a thoughtful ballpark estimate, ready access to time sheets and frequent progress updates can lead to a successful project outcome for both parties.

Connect with us