UPDATE: I've posted a followup.
I was recently contacted by my first Greek potential client, wanting to do some new features in a small Django application. I quoted him my hourly rate and he was shocked! He wanted me to quote a fixed price for the features he wanted, and I strongly declined. The outcome?
We ended up working together, he is very pleased with both the results and the money he's paying, and I didn't budge on my initial quote. Here are the arguments I used to support that an hourly rate is better for everyone. Hopefully they will help somebody else as well.
I like to link software development to erecting a building, starting only from a plot of land. The process usually goes like so:
- Here's the patch of land we want to build on.
- Here's some more-or-less vague sketches of what we want to build.
- Can you quote us an exact price for it?
Any engineer would immediately recoil from such a suggestion, however many times software developers, probably anxious to close the deal, will do a wild estimate, double it and add 30% and hope for the best.
Back to harsh reality
Here's my response:
- My hourly rate is XX/hour.
- I can spend 2-3 hours free of charge, trying to define the scope of what you want.
- After that, I will start charging, even for a 5 minute telephone conversation.
- The rule of thumb is: If I am doing something which I wouldn't do if it weren't for your project, you get charged for it.
My client was terrified. His first response was that XX/hour is way too much. He mentioned other developers that have wasted his time and money and left him with unusable crap. His fear was valid - how do I know I can trust you?
A valid question
I then presented him with the following facts:
- XX/hour may seem too much, but a) I'm good and b) I'm fast.
- I use a time meter (much like a taxi driver) to accurately track my time.
- I am honorable. I will not overcharge you.
- Before embarking on any task, I will give you reasonable estimates.
- Those estimates will not exceed 4 hours.
- If at any point I realise something is going to exceed my estimate, I will present you with alternatives and you will decide the course of action.
Let's visit those one by one.
I'm good and fast.
Really, if I can get something done in 1 hour where someone else would need 3, do you end up paying less or more? Enough said.
I mean it - I press "start" when the editor launch, "stop" once I've checked in. Any interruption longer than 30 seconds and I will pause the meter. I give daily reports (automated, of course) so the client can track the cost and can budget accordingly.
I could easily overcharge you. I hold all the domain knowledge, and I can claim I spent 2 hours where I spent half. I would probably be able to slip in a dozen extra hours per month. It's not worth it. My reputation is far more valuable than any amount of short-term money. I plan on getting references and leads from a happy client, and any suspicion of being dishonest will ruin that chance.
You won't have to worry about hidden costs. I will let you know, to my best efforts, what the potential costs are going to be, and you get to decide and prioritise. I will not disappear for a month then come back with a finished product.
This one is tricky. I use this handy rule - if I feel a feature is going to take more than 4 hours, I write down "UNKNOWN". Think of it as asking someone to paint a room of unknown dimensions. Any figure he'll be giving you is going to be random. In the case of software, I will need to spend some time planning and thinking about the feature before coming up with an estimate. And you get billed for that time, as well.
This particular client understood this immediately, and he is now giving me very detailed specifications, data schemas, even mockups of the interface. This way he keeps his bill low and he also ensures feature creep is not going to destroy his project.
That last point is of particular value. Any client will have grand dreams of his product. He will constantly ask for new things, and think those were naturally implied from his vague sketches. If you have quoted a fixed price, and you were smart enough to have a detailed contract, you will need to fight him on every step, saying "we didn't spec that". Whereas, with an hourly rate, you can say "sure, let me estimate how much will this be". The client can then decide if it's worth the money.
Uncertainty and unknowns
In software, it is quite expected that unforeseen problems will arise and budgets will slip. There are two ways to deal with this:
- Try to factor the risk into your price or
- be honest with the client and let him decide what the outcome will be.
With the first way, the client may overpay for something that wasn't really necessary, or the developer must live with the anxiety of overshooting your budget and working for free.
With the second way, the client will need to pay more only if necessary, and he is part of the decision making process.
This whole essay is about Agile Project Management. I'm the expert on managing software projects, my client is not, hence I need to educate him. I don't really care about the whole array of tricks available to manage software teams, only about some core topics:
- Daily results
- Constant communication
Keeping the tasks small enough to be completed within a day means I can show my client daily results. Compare that to the previous developer, who vanished for 6 months and delivered a piece of crap.
Daily results mean the he can steer the project to where he wants, because I allow him to see if what he thought he wanted is what he really wanted. We communicate daily - once before I start work, having a brief chat about the feature I'm about to implement, and once after I finish, where I ask him to have a look and see if that's what he wanted. This puts the client in power, because he's the one making the decisions, and his decisions doesn't cost a ridiculous amount of money.
Those two items help build trust. The client, seeing daily results and interacting in a professional way, is convinced that indeed my hourly rate is worth it and he is getting exactly the things he wants.
I firmly believe that this way of working gives both the client the best result for the least amount of money, and provides me with the peace of mind that I will not work for peanuts because of a bad estimation made on shaky evidence.
This post is older than 30 days and comments have been turned off.