Should you pay your developer one lump sum, up front?
Should they get half now, and half when the job is done?
Is it safe to pay them hourly, or will they waste time and run up your bill?
These are all valid questions, and I’d like to take a moment to address them, as I’ve had some experience on both ends of each of these scenarios.
Use a Medium
For the sake of argument, I am assuming that you are paying a contractor through some kind of portal. Either they’re on Odesk, Elance, or working through some other program that tracks their work.
Secondly, I’m assuming that, because you’re using this portal, you also have a medium through which to dispute any potential payment or contract problems. I highly recommend you hire programmers through another site, where you can view their feedback, their history, and their work. This also allows you to keep better tabs on what they’re doing for you once the job begins.
Enough said.
The Advantage of Fixed Price Jobs
As employer, you will naturally gravitate towards this option. And, that’s to be expected. After all, you want to save money andensure that you don’t get into a situation where you’re paying out more than you bargained for.
This is a fair point of view. Their are numerous situations where a fixed price contract is, I think, I fantastic option. Here are a few scenarios in which I would hire a programmer at a fixed rate:
- The project is relatively short and simple (a few days work).
- I know exactly how much work needs to be done, and how long it should take a competent programmer.
- I don’t plan on making any changes to my project during or after it’s completion. Everything, down to where the buttons and form fields are located, is set in stone.
- I don’t care that much about how it’s done, and it’s a relatively low-cost job that I just want someone else to handle. As long as they finish it, I’m going to be hands off. (This is very rare.)
Fixed price contracts are favorable agreements to both parties because everyone knows how much money is going to be spent.It removes a variable, making both programmer and employer a bit more comfortable. That being said, it also has it’s limitations.
Fixed Price Limitations
What if you want to make changes to your program or website (changes that weren’t in the contract)? What if you want to add or remove something? What if you want to cancel the project and cut your losses? What if your programmer can’t handle the project?
These are all scenarios that are a little more tricky in a fixed price situation. Most employers don’t initially consider these issues, because they’re more concerned about the finances. But, if you ask your programmer to do work (in any amount) above and beyond what was specifically agreed upon at the outset, they are not going to be happy. And I can tell you right now, that if you’re new to all of this, you are likely going to have to ask for extra features and functionality in your program (that you’re not planning for now.)
Cancellation
Secondly, if you decide to cancel the project under a fixed price contract, it’s difficult to figure out how to negotiate the situation. Do you pay a partial amount? How much work have they actually done? How do we come to an agreement?
Adding Developers
Another problem with fixed price contracts is bringing on another developer. It’s not uncommon to reach a point in your project where things just aren’t moving along as quickly as you would like. Perhaps your programmer is doing a great job, but they’re swamped with other projects. If you’ve agreed to pay them X amount, and, that was your entire budget for the project, you’re going to be hesitant to bring on fresh help because of the additional cost. You could easily double the cost of the project in order to get it done in a timely manner.
But, I think we’ve said enough about fixed price contacts. Let’s talk about hourly rates.
The Advantages of Hiring Programmers by The Hour
One thing I like about hourly contracts is that this model eliminates a great deal of the problems encountered with fixed price jobs. If I need an additional programmer, I just go find one and add them to the team. If my programmer isn’t working out, I fire them. They’ve already been paid for all the hours they’ve worked, and I am in possession of the code they have completed thus far.
Better Talent
A second advantage to hiring programmers by the hour is that you will generally attract better talent (at least on freelance sites). Experienced programmers have worked plenty of jobs and contracts, and, they know the rules of the game. Every experienced developer has had contracts that slowly got larger and larger (or more complicated than expected). When this happens on a fixed payment contract, the developer slowly watches their hourly pay sink lower and lower. And, it isn’t uncommon to end up working for minimum wage (or less).
If the contract is hourly, it’s just a minor nuisance or unexpected scenario. Either way, the developer get’s compensated and is generally ok with project scope creep.
Why should you care if your developer is happy?
Well, you want your project done professionally, quickly and correctly – right? And don’t you think the project is more likely to unfold that way if everyone is happy with the arrangement? If you felt like you were getting taken advantage of, would you feel obligated to do good work?
Saving Money
Another potential benefit is that, as an employer, you might actually save money by paying by the hour (if your developer is fast). Most people who hire for development projects for the first time don’t have a firm concept of how much time programming takes. Thus, they are likely to estimate either too much money or two little. As a result, it would be easy to overpay someone for the work they do if it’s at a fixed rate.
I’ve had more than one situation where I was prepared to shell out quite a bit more money than necessary. But as the project progressed, my programmer was able to complete the work in a fraction of the time I had anticipated. (And I’m a programmer!)
Hourly Rate Limitations
I think most people’s biggest fear with paying by the hour is that their programmer will either waste time or deceive them(since you can’t read code and you don’t know what they’re doing). While this is absolutely a legitimate concern, and does happen, it is rare in my experience.
After an interview, I generally have a pretty good feel as to whether or not I trust the person I’ve just talked to. And, this rarely fails me. In fact, I even rate the programmers I talk to on a scale of 1 – 10 in terms of ‘likeability’.
Most programmers are freelancing because they want to earn their income outside of a traditional employment setting. They want to own more of their time and learn some business skills. Consequently, most of them are trying to deal honestly and fairly with people (the best way to do business).
Another concern for many employers, is that their project will take a great deal of time, and, as a result, cost a great deal of money (if paid for by the hour). If you have a poor, inefficient, or negligent programmer – you’re right, you will waste a lot of money.
If you have a smart, intelligent, fast working programmer, you will oftentimes save money.
Conclusion
There is no right or wrong here, though, I’m guessing from reading this article you can tell my personal preference.
I like to hire by the hour.
Personally, I feel like this gives me a lot more control. I can pick who I want, I can give them big tasks or small tasks. I can hold development up for a week and pay nothing, etc…
And, I know that since most programmers prefer this form of compensation, I have a bargaining chip in my corner when I hire them, and thus, am generally able to hire better talent.
Whatever route you choose to go with, the basics of managing your project are essentially the same. If you communicate poorly, don’t explain your business and needs, don’t break down the different parts of your project, etc… it doesn’t matter what type of payment model you use, you’re likely to be dissatisfied with the results.
Be the first to comment