Ever since my first job (entering some data into excel sheets during school summer holidays) I've been asking myself this question: "does it make sense to be paid per hour if the work can be finished faster?".
For example, if you work as a guide, it does make sense to get hourly pay. But if you are doing a set task that produces a concrete result, why are you, in most cases, being paid for the hours?
I always was fast and good with my homework. It made sense to start early and to be efficient because I would get more free time. And I was faster than other people, entering rows in those datasheets. As you can guess, it did not pay off and felt super unfair and stupid (teen's thoughts).
If you are fast and efficient ultimately you get paid less for the same amount of work. And since it might be still expected for you to work full hours it is possible to get overworked and burnt out. Concentrated work is more demanding.
The incentive to be fast is lost. You start conserving energy. Thinking in hours, not in results. You don't get more free time or more money. Maybe you get a promotion a year later if you can keep up the tempo.
On the other hand, if you get paid per project it is really important to have a good estimate of the days (not hours!) you will need to finish it, so you get enough money to go on. And it is notoriously hard to do in the software world. Most of the time you have no idea how much time the project will take to finish, unless it is something standard. So it probably makes sense to pay developers for hours worked, even from the point of view of the developers.
15 years later, I am still debating this topic with myself.
It would be nice to hear about your experiences.
- Did you work in software companies that do not count how many hours you work? Or is this possible only if you are a freelancer?
- Are you a 'sprinter' or a 'steady' developer? Do you practice deep work? How many hour of it are you capable of pulling off daily/weekly?
- Which compensation type do you prefer? Maybe both, depending on a case?
Top comments (27)
Another reason to charge by the hour is to discourage clients from asking for unnecessary additions that "are obviously an implied part of the project" or just from generally wasting your time.
As a fellow 'sprinter' I've also run into this issue but have resigned myself to just letting the client benefit. I guess the right approach would be to ask a higher hourly compensation, but good luck with that...
I've seen that happening. Nothing should be "implied" for a fixed price project. If it is not in the specs, it should be charged separately. But then the specs must be really good.
Higher rates have a limit..
Are specs really possible?
What is a detailed enough spec but the implementation itself? Or at worst a test suite.
How about specifying which things will NOT be in the project? That might work in a "spirit of the law" kind of way to curb similar requests.
"so, flying unicorns are outside of the scope of the project and so are these N billions possible features"
But I love the idea! :)
I am well aware that this set is infinite, while the set of what IS included is at most as long as the code, which in bounded delivery time is probably bounded too.
But yeah, you get it. A couple of pointed examples could go a long way.
Probably not a good idea. A list of features that are not part of the agreement suggests that things outside said list can be expected. It's probably tricky one way or another unless you can reduce it to something nearly mathematical, like a set of functions, but projects are rarely like that.
It's more of a supplement. Can even come paired with the things on the list of what you will do as part of this price/time estimate.
E.g:
or
Yes but the existence of a supplement implies the need for said supplement, meaning the list of features that are included must be an inclusive list rather than an exclusive one.
Especially if legal action occurs (e.g. because the client refuses to pay), this might just come back to bite you in the ass. OTOH, I am not a lawyer, and different countries have different rules. You should probably be able to state explicitly that the "non-feature list" does not detract from the exclusivity of the "feature list" in some way.
Again though this sounds like a huge clusterfuck to me as there is no way to exactly state which features are part of the offer without extensive (unpaid!) work.
I prefer by the hour because you can better leverage the unknowns. If some issue holds you back you'll still get payed for the time resolving it, which is fair. Deadlines can change, either because of the client or some complication software-related or even some personal issue. This way, the per-hour will help because you can stop and resume whenever needed.
Regarding your concern about being faster, it just shows you could earn more per hour. While it may put you in some disadvantage when possible clients see your rate, you can always pitch that you're faster and better than the competition and your rate reflects that.
There is still going to be a limit to the hourly rate in the end, however.
I guess you're right :)
Check out Jonathan Stark's materials: ditchinghourly.com/
That's all 😁
This is a great resource, thank you for the link! I really liked the value based price approach and explanation of how to get there.
I think I might send it to my management as they struggle with the transition from hourly pay to the product/service model.
Ya, it seems to just make sense. If you have a developer who's really good at what they do, and you charge by the hour, you actually lose money because that person is too fast...
So either:
The time it takes shouldn't matter to the client - as long as they are given a pretty decent expectation of when it'll finish.
It also avoids the issue of causing clients to get upset when projects go over the estimated time (which always happens). Why should they have to pay for that? Why should they have to take on that risk?
If you charge a flat fee for the entire project, and it goes over the estimated time - it's not on them! They won't get upset at you!
Finally, it makes sense to price the result that they get, not the deliverable. That does involve having to figure out, with the client, what the reason is they want the project in the first place - does it produce more sales/money? More leads? Better reputation for the brand - which leads to more sales? etc.
Just "building a mobile-friendly website" isn't what they really want. What they might really want is "more organic search traffic to get awareness of the brand", etc. - an outcome you can measure (with SEO tools, etc.)
Once you think about it, hourly billing just doesn't make sense!
I don't get this argument. Better (faster) developers charge more per hour.
Yes, but what happens when you start charging $300+ an hour? You start losing bids.
For example, take the point I mentioned about the fact that most projects go over the estimates.
If you are charging a lot per hour and the project goes over - your client will be on your back like a rabid wolverine. Or, they just won't work with you again.
The shift is instead of charging for time and labour, you charge based on the value that the client receives.
This is a total paradigm shift. It allows you to focus on drilling into why the customer wants what they want (the root reason) and then charge for that.
This almost always means you can charge way more for the project in general, because your price isn't tied to time but to business outcomes.
For example, let's say I'm really good at helping businesses drive more sales because of skills XYZ. Specifically, I guarantee at least a 20% increase in sales per year.
Let's say it takes me 3 days worth of work to cause a 20% increase in sales by changing conversion rates, etc.
For a company making 5 million in revenue that year, that's $1,000,000 extra that I brought in. If I charge 10% of that for my project fees, then I've made $100,000.
What if I charged per hour based on the same gains? I would have to charge $100,000 / (8hrs per day * 3 days).
That's $4,167 per hour.
What sales pitch would you prefer?
Vs. the typical freelancer
Notice the difference between charging based on time and labour vs. charging based on business outcomes?
Hope that helps a bit!
Your pitches are apples v oranges and yet, I've never heard of anyone getting sold on the first one or at least not to a crook. There are continuous revenue share models where you get % but only as long as you provide value and there are success fees for one time projects as you described. The only case similar to what you describe where you put value once and gain benefits indefinitely is the VC model, but we all know it rarely works and feeds on big wins.
Even lawyers bill per hour.
We'll have to to agree to disagree 😂
I don't understand why no one mentions charging for the hour and then inflating the hours?
"Because it is hugely immoral and fraudulent"?
IMHO, especially if you work in a team, the whole team can be in on it.
The ratio should be fairly consistent, and obviously capped.
Seems like the best bet for productive developers. You give a good-looking rate and a good-looking estimate, you get hired, you get reasonably compensated for any additional features and setbacks. And everyone is happy.
Full disclosure: I've never done anything of the sort.
Isn't it funny that spending half of the time unfocused, distracted and procrastinating somehow doesn't feel hugely immoral and dishonest?
This, totally. It's the same thing, and in both cases the client can still get amazing value from the developer.
But one feels like your limitation/disability so you just merilly feel sorry for yourself, while the other feels like you're a rockstar but also a huge asshole.
This is a topic that got me multiple headaches during "Project Management" class at college 👊🏻(as a sprinter type, I got angry at the idea of getting paid less for being fast 😑)
Right now I think that it depends on the task:
Getting paid per project seems okay as long as you (or your team) feel confident with the deadline, in this case efficiency is rewarded with time that can be used for other activities. 👨🏻💻
Getting paid per hour is useful when there isn't a clear goal and the client wants you to do a bunch of stuff that may be hard to estimate. 👨🏻💻
Maybe having a mixed model could work in a lot of cases: the client pays for a project that can be delivered in a certain amount of time, but anything outside the initial scope shall be payed per hour 🤷🏻♂️
Knowing that estimating how much time is needed is usually hard when the project involves unknown domains or heavily customized functionality, I think a great advice would be to avoid committing to any form of payment before having clear requirements (whenever possible at least) 🧐
Without clear requirements, it can be a business suicide to agree on a project price. I have seen it happening. Optimistic estimations first, and endless fixes and "small" feature additions.
Then the project goes over budget or over expected time. And everyone is frustrated.
On the other hand, if it is charged by hour, but the project still does not have clear requirements, the client can get frustrated because they had some expectations on how long it is going to take and how much money they are willing to spend.
In my opinion, a huge chunk of work should be on making specifications and writing down requirements. Maybe it should be charged separately as a whole. And maybe building a prototype, if necessary, can be another "product".
I work in a web development agency and I get paid a salary per month. My timings are flexible, not the typical 9-5. As the pay is salary based, to a certain degree overtime is expected to get projects over the line. This can vary between paid and unpaid.
Our projects are usually priced based on the complexity of the site, which takes into account weeks/months. Our basic sites have a flat cost, which more often than not don't take as long as they are priced out to be. We do however have support packages and sub-contracted work that is billed per hour.
As for what type of developer I am then I'd definitely define myself as a late sprinter. I usually start a new project off quite well then as the initial enthusiasm simmers my work rate drops considerably. As milestone/internal review deadlines come closer my work rate will increase incredibly and I'll get through everything twice as fast. Makes me wonder what it'd be like if I worked at a consistent level 🤔.
As you can probably guess I'm in my procrastination phase 😅.
Typical projects are probably the best to be charged at a fixed price. You know how much time they take, and you can also invest in automating the process. The client gets the result fast, at a predictable price. Everyone is happy.
I generally don't have any deadlines, so there is a constant struggle with maintaining my productivity high. I set goals for myself and try to engage in deep work as much as I can. But then there is inevitable slow time and the guilt is often creeping in ("I am not working as fast as I could!").
The best model I know is a subscription. You are booked upfront for X hours a month (they do not roll over) at a preferential rate. Any extra hours are a bit more expensive. It reduces bureaucracy and is safe both sides.
I mostly charge per week/month.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.