5 reasons why hourly rate is better than fixed price(blog.netguru.co)
blog.netguru.co
5 reasons why hourly rate is better than fixed price
http://blog.netguru.co/post/55074277381/why-hourly-rate-is-better-than-fixed-price
18 comments
1) Nonsense, you raise your rate as you prove yourself, as someone who bills at $185+ -- clients aren't idiots. They understand that if you can do it in 1/5th the time and cost 3x the money, they are still saving money. Clients can do basic math. The only time you need to worry is if you can't prove your skill (bad references or new to market).
2) No professional ever uses the phrase "hourly" -- it is always T&M (Time and Materials). Most professionals with enough experience work in 'standard days' or 'standard weeks' on longer contracts. Last contract I did was billed at 7700 a week, no hourly accounting.
... some of what you mention (variable bill adaptation) is tricky as hell, and on FFP (Firm Fixed Price) contacts, it can be outright illegal without clients signatures at every change point. This is a reason home renovators always have change request forms with them.
~ Beyond all that, FFP puts you at odds with your client, you want to fuck them by charging as much as you can and working as little as you can -- they want to bleed you for as many hours as they can while keeping you bound to the initial contract. Nothing like starting a contract as sworn enemies.
2) No professional ever uses the phrase "hourly" -- it is always T&M (Time and Materials). Most professionals with enough experience work in 'standard days' or 'standard weeks' on longer contracts. Last contract I did was billed at 7700 a week, no hourly accounting.
... some of what you mention (variable bill adaptation) is tricky as hell, and on FFP (Firm Fixed Price) contacts, it can be outright illegal without clients signatures at every change point. This is a reason home renovators always have change request forms with them.
~ Beyond all that, FFP puts you at odds with your client, you want to fuck them by charging as much as you can and working as little as you can -- they want to bleed you for as many hours as they can while keeping you bound to the initial contract. Nothing like starting a contract as sworn enemies.
Exactly. I was just going to raise the same issue as #1.
From freelancer/agency point of view: why are we supposed to charge less only because we have skills to do things faster?
From client point of view: what's their motivation to do things as fast as they can? I'm paying them for each and every hour anyway so why would they rush?
From freelancer/agency point of view: why are we supposed to charge less only because we have skills to do things faster?
From client point of view: what's their motivation to do things as fast as they can? I'm paying them for each and every hour anyway so why would they rush?
Agree wholeheartedly, I wrote something similar in a comment above, but the title of OP made me cringe really hard. If you are in an ocean of samesies it might be worth to fight in hour prices, but if your fixed price / competitor hour is cheaper, with you making 10 times more, DO NOT LIMIT YOURSELF.
1) That is a big problem. Really hard to convince people you are more than 3x as good as the 3x cheaper alternative. But than again lawyers manage to do it. Why would web developers not figure it out? ;)
2) Yes. It does not scale in a way "startup people" are used to. It's just part of the deal :(
2) Yes. It does not scale in a way "startup people" are used to. It's just part of the deal :(
This is exactly why you might want to consider moving to weekly billing. Bill for a weeks work, as long as the deliverables come in does it matter if the week was only a few hours long?
You can either charge a lot per week, or less per week and still fit in more clients
However there is still a lot or marketing to do
You can either charge a lot per week, or less per week and still fit in more clients
However there is still a lot or marketing to do
So are you essentially telling the client that you are billing them for the week - which means you are dedicated to their project for the week?
no, you are saying that next week I will work on the deliverables we agreed for the week. And I will deliver them. And they will bring you this much benefit.
If I need to go and hire two guys and work nights to do it, I lose. But I only lose a limited amount.
SO, I guess I really am saying work fixed bids of one week projects.
If I need to go and hire two guys and work nights to do it, I lose. But I only lose a limited amount.
SO, I guess I really am saying work fixed bids of one week projects.
So if you finish them in one day - you don't send them to the client until Friday?
I imagine if you did them in a day or two the client would be asking why they paid for a week of work and if they can use the rest of the time somewhere else
I imagine if you did them in a day or two the client would be asking why they paid for a week of work and if they can use the rest of the time somewhere else
Why not keep them till the scheduled Friday meeting?
The client is expecting it Friday, probably does not have time to talk to you on Tuesday afternoon.
Its not lying, its not cheating, its saying I will build X and doing it in a professional manner.
The client is expecting it Friday, probably does not have time to talk to you on Tuesday afternoon.
Its not lying, its not cheating, its saying I will build X and doing it in a professional manner.
Are you sure?
> Bill for a weeks work, as long as the deliverables come in does it matter if the week was only a few hours long?
"Hello Mr Client, this job will take a week to do, so I need to bill you for a week of my time". 4 hours + 1 meeting on Friday, job done.
That sounds like lying and cheating to me. Which is a nuisance, as I'd like to do it.
> Bill for a weeks work, as long as the deliverables come in does it matter if the week was only a few hours long?
"Hello Mr Client, this job will take a week to do, so I need to bill you for a week of my time". 4 hours + 1 meeting on Friday, job done.
That sounds like lying and cheating to me. Which is a nuisance, as I'd like to do it.
It is lying and cheating, and it is illegal.
Generally 'standard weeks' are done under the assumption that you will work at least 40 hours on the project (often more, I average 44). The concept is that the project is significantly more than 40 hours, and accounting for every moment is overhead that doesn't serve anyone. Client doesn't care and it simply wastes your time to do it.
Generally 'standard weeks' are done under the assumption that you will work at least 40 hours on the project (often more, I average 44). The concept is that the project is significantly more than 40 hours, and accounting for every moment is overhead that doesn't serve anyone. Client doesn't care and it simply wastes your time to do it.
Its not lying and cheating nor illegal to say "I will build you a purple widget for your website, you can have it by Friday. The widget will cost you 1000 bucks"
Get away from selling your time please. Sell something else, sell a feature, sell a widget, sell a service. As a "bum on seat" I have charged by the hour, the day, the week or even a month. And each an every time I was expected to, contracted to do 8 hours a day, 5 days a week.
I was an employee.
I could not supply them a simple single product, custom built for them because I had to wade through meetings and politics and inertia and everything else we all know and love. They were too disorganised, too chaotic, too out of control to know what they wanted at a level below "months of work from dozens of people", and so the ride continued.
This is where the Internet is opening up new opportunities - because now it is dismantling (read automating) traditional marketing and even management. One guy can reach a global audience with good SEO, and one group of people can do away with 80% of industrial world management (including geo-co-location). And all that will dismantle the chaotic crazy world of contractors selling their time inside corporations who need software but are not able to deal with the implications.
The contracting world will look very different in ten years. It will look a lot like what patio11 is selling.
So, stop selling your time - instead sell a packet of something, for about the price of a week of your time, to do something that will take about a week of your time.
It looks a lot like selling a week of your time, except that
* it does not say so in the contract
* it is something you can and will automate.
Selling a product is 80%+ automated and 20% custom.
Selling a productised-consult is 20% automated and 80% custom.
The more that 80% dives down, the more profit you make in your "week". However the more it looks like a product, the less you can charge :-)
Do I care that my accountant only spends an hour looking over an annual return he got by pressing a button, yet charges a grand? No, because I make up for it on chats over coffee and the knowledge that he would catch the horror of a mistake and fix it. No horror, good for him. However that week he did tackle a horror for someone. Next time it will be me.
Get away from selling your time please. Sell something else, sell a feature, sell a widget, sell a service. As a "bum on seat" I have charged by the hour, the day, the week or even a month. And each an every time I was expected to, contracted to do 8 hours a day, 5 days a week.
I was an employee.
I could not supply them a simple single product, custom built for them because I had to wade through meetings and politics and inertia and everything else we all know and love. They were too disorganised, too chaotic, too out of control to know what they wanted at a level below "months of work from dozens of people", and so the ride continued.
This is where the Internet is opening up new opportunities - because now it is dismantling (read automating) traditional marketing and even management. One guy can reach a global audience with good SEO, and one group of people can do away with 80% of industrial world management (including geo-co-location). And all that will dismantle the chaotic crazy world of contractors selling their time inside corporations who need software but are not able to deal with the implications.
The contracting world will look very different in ten years. It will look a lot like what patio11 is selling.
So, stop selling your time - instead sell a packet of something, for about the price of a week of your time, to do something that will take about a week of your time.
It looks a lot like selling a week of your time, except that
* it does not say so in the contract
* it is something you can and will automate.
Selling a product is 80%+ automated and 20% custom.
Selling a productised-consult is 20% automated and 80% custom.
The more that 80% dives down, the more profit you make in your "week". However the more it looks like a product, the less you can charge :-)
Do I care that my accountant only spends an hour looking over an annual return he got by pressing a button, yet charges a grand? No, because I make up for it on chats over coffee and the knowledge that he would catch the horror of a mistake and fix it. No horror, good for him. However that week he did tackle a horror for someone. Next time it will be me.
As he said, he's selling a fixed bid project that is scheduled for a week.
The client he's looking to work with is looking for results, not how long he spends sitting in front of an IDE.
The client he's looking to work with is looking for results, not how long he spends sitting in front of an IDE.
Brennan, I respectfully disagree. He said:
"This is exactly why you might want to consider moving to weekly billing. Bill for a weeks work, as long as the deliverables come in does it matter if the week was only a few hours long?"
What you sond to be advocating is fixed-price bidding/value-added pricing; but that's not the same as the OP.
If he'd said: "This is exactly why you might want to consider moving to billing on value. Bill based on what it's worth to them, as long as the deliverables come in does it matter if it only took a few hours?" I'd have had no qualms.
"This is exactly why you might want to consider moving to weekly billing. Bill for a weeks work, as long as the deliverables come in does it matter if the week was only a few hours long?"
What you sond to be advocating is fixed-price bidding/value-added pricing; but that's not the same as the OP.
If he'd said: "This is exactly why you might want to consider moving to billing on value. Bill based on what it's worth to them, as long as the deliverables come in does it matter if it only took a few hours?" I'd have had no qualms.
Gotcha. I misread. He misspoke. And yes, life is still good :-)
I reserve the right to mis-speak. Especially if I clarify in later posts ;-)
Mis-speak accepted :)
I agree...but. You probably only ever get to fixed pricing (successfully) once you've learned to value your hours, which you probably learned by years of selling them.
Of course - been at it for 8 years and have learned a lot. It also depends on what the market can handle.
Design is billable work. Just because we can build a shed without a blueprint doesn't mean we should attempt anything on/in a house that's major.
And here's one reason that overrules all 5: because the customer doesn't like surprise pricing.
Their business is knowing how much something is going to cost. This isn't exclusive to the project I'm working on with them. This extends to every aspect of running their business. Whenever I see a business owner angry about a new government policy being considered that would impact their business, they're rarely upset about the policy itself and more upset about the vagaries that come with being affected by the enigmatic legislation process. Small businesses and even medium sized businesses flourish under consistent understanding of their costs.
Even if I'm not as big a shop or even as talented a shop as the next guy, I know almost any company is going to go with me because I will give them a number and I won't deviate from it unless they, themselves, have deviated so far from the scope that I have to forewarn them that the project needs to be re-estimated. At which point they understand because they're a business owner too.
Moreover, it just feels sheisty. It feels like a bait-and-switch. If I severely underestimate my costs on a project, I shouldn't be passing that mistake along to the customer. It's not their fault. It's mine. I'm the expert here. I'm the professional in this field they hired me to be the professional in. How can I go back to them and ask for more money because I didn't prove myself to be professional? It's not their concern how I run my business, nor should it be.
Their business is knowing how much something is going to cost. This isn't exclusive to the project I'm working on with them. This extends to every aspect of running their business. Whenever I see a business owner angry about a new government policy being considered that would impact their business, they're rarely upset about the policy itself and more upset about the vagaries that come with being affected by the enigmatic legislation process. Small businesses and even medium sized businesses flourish under consistent understanding of their costs.
Even if I'm not as big a shop or even as talented a shop as the next guy, I know almost any company is going to go with me because I will give them a number and I won't deviate from it unless they, themselves, have deviated so far from the scope that I have to forewarn them that the project needs to be re-estimated. At which point they understand because they're a business owner too.
Moreover, it just feels sheisty. It feels like a bait-and-switch. If I severely underestimate my costs on a project, I shouldn't be passing that mistake along to the customer. It's not their fault. It's mine. I'm the expert here. I'm the professional in this field they hired me to be the professional in. How can I go back to them and ask for more money because I didn't prove myself to be professional? It's not their concern how I run my business, nor should it be.
Great point. Giving or receiving surprises is kryptonite to consulting relationships.
Part of the value we must provide is be the guide to finding and doing the things a business needs to move forward, and help communicate the risks, unknowns and things that have to be figured out before ever starting them so the customer gets to participate in things as an experiment.
Part of the value we must provide is be the guide to finding and doing the things a business needs to move forward, and help communicate the risks, unknowns and things that have to be figured out before ever starting them so the customer gets to participate in things as an experiment.
To put it a more geeky way, pretend you're building an API. Would you want your two disparate systems (your services, and the client) to "know" about each other's internals? Of course not. It's no different for business interfacing. All the client wants to know when it inputs Money into You is
1) What are the deliverables?
2) What is the value?
So that's all you should be concerned with "exposing" to their side of the API.
1) What are the deliverables?
2) What is the value?
So that's all you should be concerned with "exposing" to their side of the API.
Our "response" to this is radical transparency. Client should be able to track the progress in almost realtime.
The problem is that usually the business is not sure what it wants then the project starts - the scope is not well defined. And it's ok. This is something that all stakeholders learn along the way.
The problem is that usually the business is not sure what it wants then the project starts - the scope is not well defined. And it's ok. This is something that all stakeholders learn along the way.
And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. The second part of this is a mutual understanding that scope is gospel. This means the client has a clear understanding of the end product and what problem it's going to solve, and you're going to have the same understanding. Changes to the gospel mean changes to everything else.
Obviously running a business is part philosophy. If you don't mind a customer looking over your shoulder throughout an entire project, second guessing your time usage, then sure, I can see how an hourly situation might work. I despise that, and so I've found fixed pricing to be my preferred approach (which has the apparent added benefit of being very appealing to most clients).
Obviously running a business is part philosophy. If you don't mind a customer looking over your shoulder throughout an entire project, second guessing your time usage, then sure, I can see how an hourly situation might work. I despise that, and so I've found fixed pricing to be my preferred approach (which has the apparent added benefit of being very appealing to most clients).
"And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. "
Bingo. Hourly or fixed doesn't matter here. Both will mess up the relationship because there's no value delivered in the clients eyes.
As for the micromanaging; some customers like running a daycare for adults and babysitting everyone. I prefer to not be in these relationships and in exchange be proactive with our updates.
Bingo. Hourly or fixed doesn't matter here. Both will mess up the relationship because there's no value delivered in the clients eyes.
As for the micromanaging; some customers like running a daycare for adults and babysitting everyone. I prefer to not be in these relationships and in exchange be proactive with our updates.
> And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault.
How do you get around companies wanting a fixed price without knowing entirely what they want? As a freelancer I can't spend 2-3 days of meetings and spec writing only to lose the project because they preferred an agency/another supplier.
If I had clients who would pay for a 'Consulting' phase of producing a spec (which they could then send to other agencies/freelancers) then I could see this working, but those are like unicorns.
How do you get around companies wanting a fixed price without knowing entirely what they want? As a freelancer I can't spend 2-3 days of meetings and spec writing only to lose the project because they preferred an agency/another supplier.
If I had clients who would pay for a 'Consulting' phase of producing a spec (which they could then send to other agencies/freelancers) then I could see this working, but those are like unicorns.
Adjust the way you think of the word "scope."
To people who build websites, scope means technical scope--the features, functionality, design, backend etc. A precise technical scope makes it easy to calculate a price.
But to people who buy websites, scope means financial scope--a "$100,000 project" vs. a "$20,000 project." They don't know precisely what they want...because they don't know what is possible. That's why they are hiring you!
So you learn as much as you can in the RFP process and propose your fixed price based on that. Unless the client or RFP is a terrible lie, you should be able to get it in the ballpark.
From there, closing the sale depends on your ability to convey that your expertise will help the client get the best possible product for this "scope" (i.e. price). If you want to cover a few more bases, you can provide some optional levels of effort for the riskiest items, or "nice to haves."
To people who build websites, scope means technical scope--the features, functionality, design, backend etc. A precise technical scope makes it easy to calculate a price.
But to people who buy websites, scope means financial scope--a "$100,000 project" vs. a "$20,000 project." They don't know precisely what they want...because they don't know what is possible. That's why they are hiring you!
So you learn as much as you can in the RFP process and propose your fixed price based on that. Unless the client or RFP is a terrible lie, you should be able to get it in the ballpark.
From there, closing the sale depends on your ability to convey that your expertise will help the client get the best possible product for this "scope" (i.e. price). If you want to cover a few more bases, you can provide some optional levels of effort for the riskiest items, or "nice to haves."
It's possible to be just as transparent and flexible under a fixed price contract. And if changes need to be made, they can still be made on a change request or contract amendment.
The problem with this post is the word "hourly"; the author means "time & materials". It's fine to bill based on your time, but unless you're a furniture mover, you shouldn't be doing it in hour increments.
This is a hobby horse of mine, so I'll spare you the retread:
https://www.hnsearch.com/search#request/all&q=tptacek+hourly...
This is a hobby horse of mine, so I'll spare you the retread:
https://www.hnsearch.com/search#request/all&q=tptacek+hourly...
good point. Weekly & daily rates are probably better as few commenters suggested.
I agree with everything in the article. However, my experience as a coder has been more positive on fixed-price contracts than on hourly contracts. On hourly contracts, which I started with and have done more of, I tend to feel like I'm bleeding the client with every hour I spend, so I rush. The quality goes down and my stress levels go up. I don't spend time figuring out the best reasonable way to structure my code, and I don't play with interesting corner cases for my own amusement. With fixed-price contracts, I know the client isn't paying for my desire to write the nicest code I can come up with on that day, nor for flights of fancy onto tangents that may be more about my own enlightenment than about delivering value for them.
I realize that I should be able to fix my issues with hourly billing by separating my work into "value for client" and "my own enlightenment" for timekeeping purposes and only billing for the former. In reality though, the effort required to be constantly making this kind of judgement about everything I'm thinking about seriously disrupts my flow, and seems to be just as much effort as estimating a project ahead of time.
When I have a good relationship with a client, I can try to get the best of both worlds by giving them fixed-price-style estimates, and then asking for more money if the project ends up being more effort than I thought.
I realize that I should be able to fix my issues with hourly billing by separating my work into "value for client" and "my own enlightenment" for timekeeping purposes and only billing for the former. In reality though, the effort required to be constantly making this kind of judgement about everything I'm thinking about seriously disrupts my flow, and seems to be just as much effort as estimating a project ahead of time.
When I have a good relationship with a client, I can try to get the best of both worlds by giving them fixed-price-style estimates, and then asking for more money if the project ends up being more effort than I thought.
Down side to hourly rates:
1. Clients hate them. Very rarely do you they understand the difference between paying for your time and paying for the finish product they are asking for (and it's correlation to your effort/time).
2. I much prefer day rates over hourly rates. If something can be done in a few hours, then it should be free.
3. If you are a good developer and can develop quicker than most than doing a fixed price has a huge upside to it.
4. The number one reason for hours/days going longer than expected isn't based on developer/designer competency, but rather project management and lack of clear requirements (or changing requirements). Pinning commercials against the root cause of most delays can cause really messy situations.
If you're working with startups specifically, I typically do the following:
1. Give a rough estimation of what their project will cost.
2. Tell them that with this estimation they get X number of designer/developer days to build their project. They get to see an update of the project every 1-2 weeks and can decide how they want to use their budget accordingly.
TL;DR - I tell my clients that they are paying for my team's time and not for a web project. Otherwise, I do a fixed price and massively buffer it.
1. Clients hate them. Very rarely do you they understand the difference between paying for your time and paying for the finish product they are asking for (and it's correlation to your effort/time).
2. I much prefer day rates over hourly rates. If something can be done in a few hours, then it should be free.
3. If you are a good developer and can develop quicker than most than doing a fixed price has a huge upside to it.
4. The number one reason for hours/days going longer than expected isn't based on developer/designer competency, but rather project management and lack of clear requirements (or changing requirements). Pinning commercials against the root cause of most delays can cause really messy situations.
If you're working with startups specifically, I typically do the following:
1. Give a rough estimation of what their project will cost.
2. Tell them that with this estimation they get X number of designer/developer days to build their project. They get to see an update of the project every 1-2 weeks and can decide how they want to use their budget accordingly.
TL;DR - I tell my clients that they are paying for my team's time and not for a web project. Otherwise, I do a fixed price and massively buffer it.
1&2: Hourly is just a mark that the guy who wrote the article is clueless, he meant Time and Materials of course. Hourly, Daily, Weekly, Monthly, lets not worry too much about he subdivision of labor.
3: This is true, but it puts an ugly arrangement, you want to overcharge as much as possible, and work as little as possible. The client wants to "drag out" the contract to try to maximize the value of their investment. You are enemies from day 1.
4: This is 100% true, but unrealistic, the client often doesn't know what they want, they want you to help "defog" their vision and express it in technical terms.
3: This is true, but it puts an ugly arrangement, you want to overcharge as much as possible, and work as little as possible. The client wants to "drag out" the contract to try to maximize the value of their investment. You are enemies from day 1.
4: This is 100% true, but unrealistic, the client often doesn't know what they want, they want you to help "defog" their vision and express it in technical terms.
Very good points. One thing I don't really get though:
"2. [...] If something can be done in a few hours, then it should be free."
Why so?
Why so?
Because a client who is reliably paying you for days of work is worth a free hour or two now and then, and because the precedent that you will work for hours instead of days will come around to bite you in the ass later on.
This approach is great - giving small things for free, but isn't working for every clients. It's horrible for you when your customer is't paying a lot (small projects, low prices etc.). They are overdemanding, don't like your work, put a lot of changes and thinking that you should't do it for free.
You'll soon learn to cut these customers off. They are bad for your business, stress, and will stifle your growth.
The idea behind this is that you bill in weeks and deliver real business value so you don't have clients doing 'small projects' or low prices.
The approach is self selecting and self correcting.
The approach is self selecting and self correcting.
Exactly. No real projects are small. Anything less (IMO) is a favor and should be considered a marketing/sales event.
As a counter point, i would argue that if you're billing on an hourly rate, you're limiting your earning potential as there's only so many hours in the day and a client will compare you to others in your industry if you charge by the hour. I'll continue to beat the drum of value based pricing as patio11 does too. Deliver a project that brings the client £10,000 worth of value and charge £1,000 for it and they wont give a shit if it takes you 1 hour or 1 week.
Since I have trouble with the value extraction thing, something I also put in perspective is how fast can I finish this against the normal standards? If I can work much faster, have a well established codebase will all sorts of shortcuts to the solution, fixed price will allow me to get paid 10, 20 times more with it actually being cheaper than a normal hourly rate would cost.
Hourly makes you always take your time, I prefer to be able to compress 10 normal development hours into one as much as possible and have more free time.
For too long I have been punished for working fast with hourly rates, I avoid it like the plague. The next step after this are products.
Hourly makes you always take your time, I prefer to be able to compress 10 normal development hours into one as much as possible and have more free time.
For too long I have been punished for working fast with hourly rates, I avoid it like the plague. The next step after this are products.
When you are developing the project further how would you like to value adding new functionalities to the project using the value based pricing model?
How much value does the new feature bring to the client ?
Easy one: increase their conversion rate for google searches of keyword "blue widget" (ie google -> landing page -> credit card charged) by 5%. YOu just made them 5% of their annual turnover. Charge them a lot
Harder one: (Anything away from sales is always going to be harder to measure) Implement a simple custoemr support online chat featuire (you know the kind) - allows their support to deal with >1 person at a time, and reduces the "waiting" queue on the phone system to zero. Value? Dunno. Feel around by talking to the VP of customer service or make a judgement call like "not having to hire another five custoemr service people"
Easy one: increase their conversion rate for google searches of keyword "blue widget" (ie google -> landing page -> credit card charged) by 5%. YOu just made them 5% of their annual turnover. Charge them a lot
Harder one: (Anything away from sales is always going to be harder to measure) Implement a simple custoemr support online chat featuire (you know the kind) - allows their support to deal with >1 person at a time, and reduces the "waiting" queue on the phone system to zero. Value? Dunno. Feel around by talking to the VP of customer service or make a judgement call like "not having to hire another five custoemr service people"
This makes sense when you have a well established business that's tweaking it's processes. Impossible when building an MVP and/or experimenting.
At least in the web world (which is the only one I have a whole lot of experience working in), there seems to be an interesting progression that developers go through if/when they leave the corporate world and try things on their own. Recognizing that fixed price development is very often a nasty trap is where many developers and organizations start to actually wonder about how their business model could change.
1. Fixed bid projects. Attempting to offer custom development as a package deal seems like a great way to undercut the competition; in reality it's anything but, and (among other things, including those mentioned in the article) reduces the perceived value of your work, which hurts in the long run.
2. Hourly consulting. Better, and works well for quite a while, allowing you more flexibility in your engagements and with your rate. This might even be a good long-term strategy for individuals; however, it requires very good planning and workload management, which are more difficult than many people think. It also does limit your earning potential, but this is much more of a factor if you expand into a consultancy, in which case your expenses will drop your margin.
3. Product/subscription service development. Often the subject of HN discussion (and rightly so), the prospect of recurring revenue is obviously a powerful one. However, even more than when selling development services, this requires a solid understanding of your target audience(s) and the ability to market to them effectively, in addition to understanding end-user customer support.
Where do we go from there? I personally have no clue; I've been slowly climbing this ladder myself.
1. Fixed bid projects. Attempting to offer custom development as a package deal seems like a great way to undercut the competition; in reality it's anything but, and (among other things, including those mentioned in the article) reduces the perceived value of your work, which hurts in the long run.
2. Hourly consulting. Better, and works well for quite a while, allowing you more flexibility in your engagements and with your rate. This might even be a good long-term strategy for individuals; however, it requires very good planning and workload management, which are more difficult than many people think. It also does limit your earning potential, but this is much more of a factor if you expand into a consultancy, in which case your expenses will drop your margin.
3. Product/subscription service development. Often the subject of HN discussion (and rightly so), the prospect of recurring revenue is obviously a powerful one. However, even more than when selling development services, this requires a solid understanding of your target audience(s) and the ability to market to them effectively, in addition to understanding end-user customer support.
Where do we go from there? I personally have no clue; I've been slowly climbing this ladder myself.
This is pretty much the exact path I took. It becomes really interesting when it finally dawns on you that there's very little difference between building and selling a 3 to 4 figure / mo SaaS and offering a value-oriented consulting retainer to a few clients. (See http://draft.nu/revise/)
While retainers aren't exactly turnkey (they'll generally require human effort per account per month), the same positioning, marketing, and pricing rules you'll encounter selling software apply.
While retainers aren't exactly turnkey (they'll generally require human effort per account per month), the same positioning, marketing, and pricing rules you'll encounter selling software apply.
My experience has been the opposite, and I think fixed price benefits both sides. Of course, it depends on the circumstance. Fixed price and hourly each have their place. I will say that a fixed price contracts can be tricky.
My primary point of reference is a medium sized fixed price project that was delivered early, and the customer loved the solution and came back for more business. I've also worked countless hourly contracts from both the customer and consultancy side.
1. Assuming a fixed price project requires a big up front spec is wrong. Follow lean/agile principles, iterate and refine. The contract should specify high level basic functionality and the problem being solved.
2. Hard to quantify, but hourly is plenty risky having worked both sides of the relationship. I've seen hours and hours burned building things that are not at all necessary. A fixed price helps everyone focus on building precisely what is needed.
3. Hourly rates put customer and consultant's priorities in line? From a short term view, if I'm paid hourly I'm going to milk the deal. If the consultancy is taking a long term view, everyones priorities are in line. Consultancy delivers fantastic product on time, it's a win by bringing the customer back, and word of mouth.
4. Again, it's how you structure the contract. If a giant spec is written up as part of a contract, you're doomed before you begin.
5. I'd argue the fixed price is a risk balance between the customer and consultancy. If the consultants finish early, they're rewarded. If they are late, they are penalized. This is in contrast to hourly, where it's win-win for the consultant.
My primary point of reference is a medium sized fixed price project that was delivered early, and the customer loved the solution and came back for more business. I've also worked countless hourly contracts from both the customer and consultancy side.
1. Assuming a fixed price project requires a big up front spec is wrong. Follow lean/agile principles, iterate and refine. The contract should specify high level basic functionality and the problem being solved.
2. Hard to quantify, but hourly is plenty risky having worked both sides of the relationship. I've seen hours and hours burned building things that are not at all necessary. A fixed price helps everyone focus on building precisely what is needed.
3. Hourly rates put customer and consultant's priorities in line? From a short term view, if I'm paid hourly I'm going to milk the deal. If the consultancy is taking a long term view, everyones priorities are in line. Consultancy delivers fantastic product on time, it's a win by bringing the customer back, and word of mouth.
4. Again, it's how you structure the contract. If a giant spec is written up as part of a contract, you're doomed before you begin.
5. I'd argue the fixed price is a risk balance between the customer and consultancy. If the consultants finish early, they're rewarded. If they are late, they are penalized. This is in contrast to hourly, where it's win-win for the consultant.
If you don't know the contractor well, you don't know how hours worked translates into productivity. The programmer could be a 10x programmer or string you along saying things took longer than expected and suddenly your budget is bloated. I like a happy medium of fixed price with variable scope or a budget range with variable scope and finer details discussed in the contract.
The model that works best for me is a fixed price based on initial scope with additional fixed or hourly billing for 1) tech support and 2) additions to scope or changes that occur after sign-offs.
Hourly billing is great until it comes time for final payment, which is when the client comes back and says "ok, why did x take you 3.267 hours and y took you 4.535 hours. Can we shave off some of this and that, oh, and this, too?" "Ok, this total is a little more workable, but I'll tell you right now that our billing department won't pay a dime more than $z, so you better adjust your rate or take off some more time."
Then you end up getting screwed out of money. This happens even when you do an estimated cost and have clients pay you 50% of the estimate up front. Fixed billing sets the expectations of how much work will be done and what the client should expect ahead of time, so it's a much easier pill for them to swallow when it comes time to pay up.
Hourly billing is great until it comes time for final payment, which is when the client comes back and says "ok, why did x take you 3.267 hours and y took you 4.535 hours. Can we shave off some of this and that, oh, and this, too?" "Ok, this total is a little more workable, but I'll tell you right now that our billing department won't pay a dime more than $z, so you better adjust your rate or take off some more time."
Then you end up getting screwed out of money. This happens even when you do an estimated cost and have clients pay you 50% of the estimate up front. Fixed billing sets the expectations of how much work will be done and what the client should expect ahead of time, so it's a much easier pill for them to swallow when it comes time to pay up.
1. Weekly sprints, weekly billing. No cash delivered after 14 days, down tools and call them to say why.
There's a big misunderstanding here, which is that fixed price implies a waterfall methodology. This is not true. All a fixed price does is cap the financial scope of the project.
But the tradeoff is that you need to vary the technical scope. For this reason, agile methodology is actually the best way to do a fixed-price contract. Every sprint is an opportunity to reconsider the technical scope to stay within schedule and budget.
This does reduce risk for the client. Most companies have much more serious limitations on budget and schedule, than they do on their imagination for what an ideal site should do.
And even if the client does decide they want to spend more money to get more functionality, they can just execute a change request or amendment--a process that is much more controlled and transparent (from the client perspective) than just working a few more hours.
But the tradeoff is that you need to vary the technical scope. For this reason, agile methodology is actually the best way to do a fixed-price contract. Every sprint is an opportunity to reconsider the technical scope to stay within schedule and budget.
This does reduce risk for the client. Most companies have much more serious limitations on budget and schedule, than they do on their imagination for what an ideal site should do.
And even if the client does decide they want to spend more money to get more functionality, they can just execute a change request or amendment--a process that is much more controlled and transparent (from the client perspective) than just working a few more hours.
Any project has a defined scope and set of requirements. If you start the project before these are defined, you're dumb, because you have no idea what you're working on.
I always draft a requirements document for my freelance customers, and spell out exactly what I will do for exactly how much money, by a deadline. This document also says in no uncertain terms, that any deviations will result in a new set of requirements, and thus, a new price.
Hourly rates punish you getting better (why shouldn't I charge the same I did last month for something, despite having found a way to do it twice as fast?) and they open you up for all kinds of "why is this taking you so long" or "I'm paying you X per hour! That's more than I pay my shrink!" comments.
I always draft a requirements document for my freelance customers, and spell out exactly what I will do for exactly how much money, by a deadline. This document also says in no uncertain terms, that any deviations will result in a new set of requirements, and thus, a new price.
Hourly rates punish you getting better (why shouldn't I charge the same I did last month for something, despite having found a way to do it twice as fast?) and they open you up for all kinds of "why is this taking you so long" or "I'm paying you X per hour! That's more than I pay my shrink!" comments.
One of the points in the article is that it's impossible (and impractical) to scope out everything before you start.
I'll admit there's a certain "fudge factor" but the more experience you get with requirements gathering, the less of an issue it is. Ultimately, this is the difference between a "Developer" and an "Engineer".
It's not about the lack of skill on the supplier side. It's usually the client that is not sure how exactly the project should look like. And that's ok - he does not need to scope out every detail - it can be worked out along the way.
15 years of consulting left me dreading reading this article a little.
There is no set formula that I've found. I'm open to finding it. Until then better I get at business, the better I get at all these different ways of "earning" formulas.
You exist to help the customer get the result they want, who usually don't know what they want.
If you don't know what you're doing, or worse, don't know how to help the customer find what they need, the meter can be run up hourly, or lose your shirt fixed price. Both are poor delivery of value for the customer in retaining a sustainable, no-surprise-giving, stable business partner.
The second we are in consulting, we're in business, not an hourly employee. It's a comfort net to say otherwise of not having to learn business skills.
Still, businesses are great customers. They're a lot more logical than consumers. They especially listen to anything that adds value to their business.
What's this hokey "add value" thing?
One definition is:
Saving or making your customer money, or time.
Time? Yes. The cost of their employees is the #1 cost in their business.
So, if person x spends 5 hours a week generating a spreadsheet at $15/hour, and there's 50 working weeks a year, this spreadsheet cost them $3750 in 1 year.
That's just $15/hr!
If I spent 10 years learning to do something in 2 hours, should I charge the customer the 2 hours, for the 10 years it took to learn, or say.
"This is costing you $4000 a year, I can get rid of it for $1000 permanently".
If it's a large company, you can even look at the savings over 2 or 3 years.
See? You're saving your customer money. Get the sign-offs on any solution from the ground up to the signing authority and put good decisions in front of them.
One reality is you end up doing a bit of both fixed and hourly. The better you understand your clients business, data and processes, the more fixed you can go.
With new clients, for example, I do small fixed price projects to minimize risk for the client and to build small momentum building wins.
When customers see the value themselves, instead of trying to trick them into liking you, what they pay me becomes far less of an issue. Some still prefer hourly so I just quote the total number and let them imagine what the hourly rate is. Some still want to know the hourly rate and I let them know we work extremely fast and have 15 years of experience each.
Regardless of hourly or fixed, if at the end of it they look at it and say "yes, they built what I asked but it wasn't what I wanted", customers will start doubting good decisions in the future because your inability to guide the canoe better. This is a bigger threat to your business than anything, especially if you want to stay in consulting.
Help your customers spend their money with the care as if it was your own, and you'll find yourself with as many long term consulting customers over the years that you can handle.
There is no set formula that I've found. I'm open to finding it. Until then better I get at business, the better I get at all these different ways of "earning" formulas.
You exist to help the customer get the result they want, who usually don't know what they want.
If you don't know what you're doing, or worse, don't know how to help the customer find what they need, the meter can be run up hourly, or lose your shirt fixed price. Both are poor delivery of value for the customer in retaining a sustainable, no-surprise-giving, stable business partner.
The second we are in consulting, we're in business, not an hourly employee. It's a comfort net to say otherwise of not having to learn business skills.
Still, businesses are great customers. They're a lot more logical than consumers. They especially listen to anything that adds value to their business.
What's this hokey "add value" thing?
One definition is:
Saving or making your customer money, or time.
Time? Yes. The cost of their employees is the #1 cost in their business.
So, if person x spends 5 hours a week generating a spreadsheet at $15/hour, and there's 50 working weeks a year, this spreadsheet cost them $3750 in 1 year.
That's just $15/hr!
If I spent 10 years learning to do something in 2 hours, should I charge the customer the 2 hours, for the 10 years it took to learn, or say.
"This is costing you $4000 a year, I can get rid of it for $1000 permanently".
If it's a large company, you can even look at the savings over 2 or 3 years.
See? You're saving your customer money. Get the sign-offs on any solution from the ground up to the signing authority and put good decisions in front of them.
One reality is you end up doing a bit of both fixed and hourly. The better you understand your clients business, data and processes, the more fixed you can go.
With new clients, for example, I do small fixed price projects to minimize risk for the client and to build small momentum building wins.
When customers see the value themselves, instead of trying to trick them into liking you, what they pay me becomes far less of an issue. Some still prefer hourly so I just quote the total number and let them imagine what the hourly rate is. Some still want to know the hourly rate and I let them know we work extremely fast and have 15 years of experience each.
Regardless of hourly or fixed, if at the end of it they look at it and say "yes, they built what I asked but it wasn't what I wanted", customers will start doubting good decisions in the future because your inability to guide the canoe better. This is a bigger threat to your business than anything, especially if you want to stay in consulting.
Help your customers spend their money with the care as if it was your own, and you'll find yourself with as many long term consulting customers over the years that you can handle.
Mentioned it before in another thread here: This makes sense when you have a well established business that's tweaking it's processes. Impossible when building an MVP and/or experimenting with a new product/service.
Disagree. Absolutely possible.
I currently build MVP's, in 30-90 days if it can be pushed that fast. I'm a lean practitioner for over 10 years starting in manufacturing.
You want to help your MVP's become long term customers by helping them grow and make money. If they don't get this, it's a real risk to their business, let alone your relationship with them.
For MVP's: You have to invest in understanding your tools and how long it will take to identify and build only the features that customers can't live without.
My original consulting business is for established businesses, but they were all smaller 4-7 years ago.
I currently build MVP's, in 30-90 days if it can be pushed that fast. I'm a lean practitioner for over 10 years starting in manufacturing.
You want to help your MVP's become long term customers by helping them grow and make money. If they don't get this, it's a real risk to their business, let alone your relationship with them.
For MVP's: You have to invest in understanding your tools and how long it will take to identify and build only the features that customers can't live without.
My original consulting business is for established businesses, but they were all smaller 4-7 years ago.
"build only the features that customers can't live without" - who makes this call? What if you disagree on this? What if the customer learns something new after 2 weeks and needs to change the scope?
Who makes the call?
If it's truly a lean MVP, the end user/paying customer. Is it an MVP is if no one is getting out of the building and talking to customers/users before designing or writing a line of code?
Completing the problem solution fit, product market fit, and engaging in customer development prior to writing a line of code has to happen if we are wanting to be honest when using a term like MVP.
If you feel this is a binary issue: ultimately the person signing the cheques make the call, and you have a choice on whether to accept said cheque for managing said potential headache.
The grey area in between:
If the customer wants to do whatever they do and call it an MVP by sprinkling the lean dust on it to justify it, you have to recognize it for what it is and either adjust your approach, or decide if that kind of work is something you can live with. No process can correct development pagentry, management/design by committee, and failing to get out of the building.
Building an MVP requires getting through the build - measure - learn loop as quickly as possible.
Interrupting you mid-cycle if it's that ground breaking (customers are saying I'm trying to find a way to give you money) requires answering "Did we really understand anything before hallucinating an MVP ourselves"?
It leaves a few options:
- Change the scope
- Change the deadline
- Change the budget
- Trade features -- something that was important can no longer be important as a result of what was traded.
Avoiding this is the business skills development we all constantly need that I mention to in my initial post.
For me, I try to make sure I understand, and the customer understands why we're doing the things we want first and hopefully minimize the above.
I don't rush customers into building something, but rather rush into understanding what our experiment is, and why we're testing those things. It helps create a checklist to test our assumptions/discoveries against when the next great insight comes in.
If it's truly a lean MVP, the end user/paying customer. Is it an MVP is if no one is getting out of the building and talking to customers/users before designing or writing a line of code?
Completing the problem solution fit, product market fit, and engaging in customer development prior to writing a line of code has to happen if we are wanting to be honest when using a term like MVP.
If you feel this is a binary issue: ultimately the person signing the cheques make the call, and you have a choice on whether to accept said cheque for managing said potential headache.
The grey area in between:
If the customer wants to do whatever they do and call it an MVP by sprinkling the lean dust on it to justify it, you have to recognize it for what it is and either adjust your approach, or decide if that kind of work is something you can live with. No process can correct development pagentry, management/design by committee, and failing to get out of the building.
Building an MVP requires getting through the build - measure - learn loop as quickly as possible.
Interrupting you mid-cycle if it's that ground breaking (customers are saying I'm trying to find a way to give you money) requires answering "Did we really understand anything before hallucinating an MVP ourselves"?
It leaves a few options:
- Change the scope
- Change the deadline
- Change the budget
- Trade features -- something that was important can no longer be important as a result of what was traded.
Avoiding this is the business skills development we all constantly need that I mention to in my initial post.
For me, I try to make sure I understand, and the customer understands why we're doing the things we want first and hopefully minimize the above.
I don't rush customers into building something, but rather rush into understanding what our experiment is, and why we're testing those things. It helps create a checklist to test our assumptions/discoveries against when the next great insight comes in.
Dont you think that what you are describing sounds like a huge overhead. Rather then tweaking the product you have to "trade features" with customer.
It's also something that is very difficult to scale. It's hard to expect that every person who is good on the job is also good in negotiating with customers.
It's also something that is very difficult to scale. It's hard to expect that every person who is good on the job is also good in negotiating with customers.
Project management is a real part of software development.
I make no statements about whether the developer should do the project management -- only when a good process happens, results are good.
The developers who can manage a process that they're a part of is a skill that we should all aspire to, though, because people aren't hiring us for just our technical prowess, but rather, our ability to interface those skills to finding and completing business goals.
I do agree that avoiding the scope changes while doing an iteration is essential, and can be often lessened or deferred until the next .. sprint.
I make no statements about whether the developer should do the project management -- only when a good process happens, results are good.
The developers who can manage a process that they're a part of is a skill that we should all aspire to, though, because people aren't hiring us for just our technical prowess, but rather, our ability to interface those skills to finding and completing business goals.
I do agree that avoiding the scope changes while doing an iteration is essential, and can be often lessened or deferred until the next .. sprint.
Love this quote: "The second we are in consulting, we're in business, not an hourly employee. It's a comfort net to say otherwise of not having to learn business skills."
Great comment, thanks for sharing!
Great comment, thanks for sharing!
[deleted]
I think a lot of freelancers (myself included) go through the following process:
1 - Start out with fixed price estimates based on time (I think this will take 10 hours, so I estimate £1000)
2 - Develop good relationships with clients and start just charging hourly for work done (This took 12 hours, so here's a bill for £1200)
3 - Take patio11 (et al)'s advice and start charging based on value (this 10 hour job will increase your profits by £100,000 so I'll charge you £10,000)
In short, hourly IS better than fixed price time based estimates, but fixed price value based estimates are even better.
1 - Start out with fixed price estimates based on time (I think this will take 10 hours, so I estimate £1000)
2 - Develop good relationships with clients and start just charging hourly for work done (This took 12 hours, so here's a bill for £1200)
3 - Take patio11 (et al)'s advice and start charging based on value (this 10 hour job will increase your profits by £100,000 so I'll charge you £10,000)
In short, hourly IS better than fixed price time based estimates, but fixed price value based estimates are even better.
The problem with no 3 is that not every job can be measured in $$$. Especially when you are building an MVP and/or experimenting with features.
I think your approach is definitely valid for "traditional consulting" but a bit less so for more plain webdev work.
I think your approach is definitely valid for "traditional consulting" but a bit less so for more plain webdev work.
I disagree. Every job can be measured in terms of value. Especially mutually agreeable value. These though, are business skills and not tech skills.
But than you are introducing overhead of deciding this. For obvious reasons this is something that needs to be negotiated with a client and documented.
The only problem with value pricing is its not for every client. Its very hard to sell a client on value - especially if they are skeptical. And if your work doesn't increase value then your in a sticky situation.
There are a lot of counterpoints here saying that fixed-price is better for us as consultants.
But this article is saying hourly-billing is better for the CLIENT.
I think this is an important distinction. Obviously there are advantages for us to doing value-based fixed-price billing, but that says nothing about the merits to our clients. If you don't do hourly billing, you should be aware of these potential gotchas, and be aware that some clients won't work with you.
But this article is saying hourly-billing is better for the CLIENT.
I think this is an important distinction. Obviously there are advantages for us to doing value-based fixed-price billing, but that says nothing about the merits to our clients. If you don't do hourly billing, you should be aware of these potential gotchas, and be aware that some clients won't work with you.
If you are ten times faster than other developers, fixed price per milestone lets you charge ten times as much. If I'm writing a custom map screen for the first time it is going to take me all day. If I'm writing it the 12th time it is more like an hour. I can charge a lot more for a custom map screen than an hour, however, even an hour at the highest hourly rate the market would bear.
5 reasons? Why not 4, or even 6?
1) Something that use to take me 10 hours to design may now take me 2 hours. Should I discount the knowledge and skill it took to learn that? I'd be earning a fraction of what someone else gets because I'm more efficient.
Raise my hourly rate you may say? You can really only go so high with your hourly rate until clients will look at you funny. $100, $125, $150, $200 - anything above that as a freelancer and you'll have problems landing clients.
2) Hourly rates also limit how much you can bill - there are only so many hours and days in the year. I prefer fixed pricing as well as calculating in variables to increase the price. So if I can tell a client takes long to respond or give feedback, I add on 10%. If there are 3 or 4 people who are giving feedback, I add 5% - etc.