Why do I work on an hourly basis?
Translation of an article by a young Greek programmer "Why I bill hourly"
Recently, my first potential client addressed me, who wanted to add several features to a small application on Django. I announced my hourly rate, which shocked him extremely - he wanted to hear a fixed price for the improvements he needed. What came of it? We work together, he is very pleased with both the results and the amounts he spends on them, but I did not give up my principles of payment. Here are the arguments that I used to defend the opinion of why the hourly rate is better for all stakeholders — maybe they will help someone else.
I like to compare software development with building construction, starting with an empty plot of land. The process looks like this:
')
Client: Here is the site on which we will build. Here are the sketches of what we want to build. Can you name the exact cost of construction?
Any civil engineer will shy away from such an offer, but programmers in their thirst for making a deal estimate the estimate, double it, add 30% and hope for the best. How do I answer this question?
I'm worth $ XX / hour. I can spend 2-3 hours for free on assessing what you want to receive. After that, I will start taking money, even for a five-minute telephone conversation. The rule is simple: if I do something that I would not do if it were not for your project, you pay for it.
My client was terrified. The first thing he said - $ XX / hour is too much! Then he reminded about other developers who spent his time and money and did nothing useful. In some ways he was right - how could he know that he could trust me? I also had an answer to that.
$ XX / hour seems like a big amount, but a) I'm damn good and b) I work fast. If I do in an hour something that someone else needs three, you end up paying less.
I use the timer and accurately measure the time spent on work. Seriously. I click "start" when I run the editor, and "stop" as soon as I make a commit. If I get distracted by more than 30 seconds, I pause the timer. Daily reports (automatic, of course) allow the customer to track costs and plan expenses.
I am noble and will not overcharge. But I could! I know the knowledge of the subject area, and I can say that I spent two hours at work, although I did it in an hour. I could squeeze in a dozen extra hours every month, but the game is not worth the trouble. My reputation is more valuable than any one-time amount of money. A satisfied client will give me recommendations and will advise me to his friends, and any suspicion of uncleanliness will destroy this prospect.
Before starting any task, I will give you a justified estimate of its labor intensity. If at some point I understand that the task will take longer than I expected, I will provide you with complete information on the options for action and you will make a decision. You do not need to worry about hidden costs: I will keep you informed about upcoming work, and let you decide and prioritize. I will not disappear for a month in order to return with a ready project and demand payment for a month.
The rating of each task will be no more than 4 hours. This is the most difficult: if I suspect that something will take more than 4 hours, I put "unknown." Imagine that you were asked to paint a room of an unknown size - any estimate of the time spent will be random. In the case of programming, I will need to spend some time planning and thinking about a solution before assessing its complexity, and during that time you also pay.
This particular client understood this very quickly, and now he gives me very detailed specifications, data descriptions, even interface layouts. In this way, he cuts down on his expenses and makes sure that the spread of opportunities does not destroy his project. The latter is very important - any client dreams of a great future for his application, and he will always demand new improvements on the pretext that their necessity follows from his sketches. If you called a fixed price and even wrote a detailed technical task, you will have to fight it at every step, proving that there was no such thing in the task! With an hourly rate, you can say, “OK, let me estimate how much it will cost you,” and then let the client decide whether it is worth it.
In the process of developing any product, almost certainly there will be unforeseen problems that are not embedded in the initial assessment of the work. There are two ways to take them into account - to put their cost in the budget from the very beginning (and either the client overpays for something unnecessary, or the developer lives in constant fear of exceeding the budget), or be honest with the client and allow him to make decisions so that he pays more only when it is really necessary.
Key elements of my approach are daily results, constant communication and trust. I believe that this allows the client to get the best results for the minimum money, and I - the confidence that I will not work for food because of an unsuccessful assessment of the project budget.
I want it too!
PS The main thing is, let's not read this article to our familiar dentists ...
Recently, my first potential client addressed me, who wanted to add several features to a small application on Django. I announced my hourly rate, which shocked him extremely - he wanted to hear a fixed price for the improvements he needed. What came of it? We work together, he is very pleased with both the results and the amounts he spends on them, but I did not give up my principles of payment. Here are the arguments that I used to defend the opinion of why the hourly rate is better for all stakeholders — maybe they will help someone else.
I like to compare software development with building construction, starting with an empty plot of land. The process looks like this:
')
Client: Here is the site on which we will build. Here are the sketches of what we want to build. Can you name the exact cost of construction?
Any civil engineer will shy away from such an offer, but programmers in their thirst for making a deal estimate the estimate, double it, add 30% and hope for the best. How do I answer this question?
I'm worth $ XX / hour. I can spend 2-3 hours for free on assessing what you want to receive. After that, I will start taking money, even for a five-minute telephone conversation. The rule is simple: if I do something that I would not do if it were not for your project, you pay for it.
My client was terrified. The first thing he said - $ XX / hour is too much! Then he reminded about other developers who spent his time and money and did nothing useful. In some ways he was right - how could he know that he could trust me? I also had an answer to that.
$ XX / hour seems like a big amount, but a) I'm damn good and b) I work fast. If I do in an hour something that someone else needs three, you end up paying less.
I use the timer and accurately measure the time spent on work. Seriously. I click "start" when I run the editor, and "stop" as soon as I make a commit. If I get distracted by more than 30 seconds, I pause the timer. Daily reports (automatic, of course) allow the customer to track costs and plan expenses.
I am noble and will not overcharge. But I could! I know the knowledge of the subject area, and I can say that I spent two hours at work, although I did it in an hour. I could squeeze in a dozen extra hours every month, but the game is not worth the trouble. My reputation is more valuable than any one-time amount of money. A satisfied client will give me recommendations and will advise me to his friends, and any suspicion of uncleanliness will destroy this prospect.
Before starting any task, I will give you a justified estimate of its labor intensity. If at some point I understand that the task will take longer than I expected, I will provide you with complete information on the options for action and you will make a decision. You do not need to worry about hidden costs: I will keep you informed about upcoming work, and let you decide and prioritize. I will not disappear for a month in order to return with a ready project and demand payment for a month.
The rating of each task will be no more than 4 hours. This is the most difficult: if I suspect that something will take more than 4 hours, I put "unknown." Imagine that you were asked to paint a room of an unknown size - any estimate of the time spent will be random. In the case of programming, I will need to spend some time planning and thinking about a solution before assessing its complexity, and during that time you also pay.
This particular client understood this very quickly, and now he gives me very detailed specifications, data descriptions, even interface layouts. In this way, he cuts down on his expenses and makes sure that the spread of opportunities does not destroy his project. The latter is very important - any client dreams of a great future for his application, and he will always demand new improvements on the pretext that their necessity follows from his sketches. If you called a fixed price and even wrote a detailed technical task, you will have to fight it at every step, proving that there was no such thing in the task! With an hourly rate, you can say, “OK, let me estimate how much it will cost you,” and then let the client decide whether it is worth it.
In the process of developing any product, almost certainly there will be unforeseen problems that are not embedded in the initial assessment of the work. There are two ways to take them into account - to put their cost in the budget from the very beginning (and either the client overpays for something unnecessary, or the developer lives in constant fear of exceeding the budget), or be honest with the client and allow him to make decisions so that he pays more only when it is really necessary.
Key elements of my approach are daily results, constant communication and trust. I believe that this allows the client to get the best results for the minimum money, and I - the confidence that I will not work for food because of an unsuccessful assessment of the project budget.
Translator comment
I want it too!
PS The main thing is, let's not read this article to our familiar dentists ...
Source: https://habr.com/ru/post/107748/
All Articles