5 ms·

For this kind of work I wouldn't recommend charging an hourly rate, because when projects like this overrun (and if it's HTML5/JavaScript the chance of it happe

by EnderMB 16y ago

For this kind of work I wouldn't recommend charging an hourly rate, because when projects like this overrun (and if it's HTML5/JavaScript the chance of it happening is likely) the employer will feel cheated if paying for longer than they expect (and let's be honest, all employers think that websites take half the time to build). The best thing to do in this instance is to find out their overall budget for this thing, break it down into an hourly wage and set an overall price based on what you feel your time is worth.

kls 16y ago
The best thing to do in this instance is to find out their overall budget for this thing, break it down into an hourly wage and set an overall price based on what you feel your time is worth. A Mechanic does not fix you car based on a total cost, they charge a hourly labor rate + parts. A lawyer bills for his services by the hour. Both will provide a best guess at what they think it will take, but if you add some work or they find some problems you eat that cost not them. Why people think software development should be any different is beyond me. If you are not getting equity in the project then you should not be working on a fixed price contract. It places all the risk on you while limiting your upside (you can only make the sticker price on the contract). Meanwhile the client has unlimited upside in this arrangement and shoulders none of the risk beyond the sticker price. the employer will feel cheated if paying for longer than they expect (and let's be honest, all employers think that websites take half the time to build). Ignorance of the discipline of software development is the employer problem, a good software developer can show them how scope creep, change in priorities and adjustments to specification has a negative impact on their expectations. If they feel cheated that is their problem to deal with, software development is not charity and if it takes twice as long to build and a developer puts in twice as many hours then they should be paid twice the hours just as any other service professional is. The client/employer is not going to say "oh wow we made twice as much as we expected off the software you developed, here you go, here is some free money". So why would the developer say "oh wow the project will take twice a long as, the employers uneducated analysis says it will, let me eat half the labor costs" That being said, only extremely experienced freelancers should consider taking a fixed price contract. It can lead to financial ruin, in almost all situations a freelancer should be insisting on time and materials, like 90% of other service professionals. The exceptions would be reproducible services where times can be estimated with certainty (e.g installing wordpress or Postgres). To answer the parent posters question, I see a lot of Senior level JavaScript freelancers charging in the area of $100-$200 hr for their services. That is what I charge and stay busy.
- EnderMB 16y ago
  > A Mechanic does not fix you car based on a total cost, they charge a hourly labor rate + parts. A lawyer bills for his services by the hour. Both will provide a best guess at what they think it will take, but if you add some work or they find some problems you eat that cost not them. You're not a Lawyer or a Mechanic, you're (possibly) a Web Developer and it's fairly standard to charge based on project, as referenced by countless guides, online resources and notably within SitePoint's Web Design Business Kit. I've already stated the reasons why you do this, because it confirms the overall cost with the client, it ensures the project will not overrun at the clients expense, and in the end the client has an overall budget for this work, not a certain amount to spend per hour. As time has shown, paying by the hour is a poor and dated way to do business on the web because building software isn't an exact science and many projects overrun. In the same vein I cannot understand why people have to treat software development as a "profession" like Lawyers or Doctors. You're selling a software solution to a client, so you should charge for that solution, in the same way that people who offer products or solutions charge. > Ignorance of the discipline of software development is the employer problem, a good software developer can show them how scope creep, change in priorities and adjustments to specification has a negative impact on their expectations. If they feel cheated that is their problem to deal with, software development is not charity and if it takes twice as long to build and a developer puts in twice as many hours then they should be paid twice the hours just as any other service professional is. That's a fantastic way not to get hired for a project. It cannot be more simple than setting a price on your time per hour, estimating how long a project will take and charging what you feel your time is worth as a lump sum. The client should not get to dictate that, because you're the expert and you'll have the better idea of how long it should take.
  - kls 16y ago
    You're not a Lawyer or a Mechanic The nature of the arrangement is more similar that not. Both do project based work as service professionals. And both have unforeseen variables that cannot be known at the time of estimating. Lawyers routinely deal with unforeseen political issue (ruling not going the way they expected) and mechanics routinely deal with unforeseen problems that are technical in nature (mechanical failure, that was not known until the heads where pulled off). Software developers routinely deal with both natures of unforeseen variables in addition to the client adding work after the estimate. Which would be akin to a mechanic giving someone a quote and then when they are half way through the project the client saying well while you are in there go ahead and change out the pistons for forged steel ones, and then arguing because the client got charged for the parts and labor. In all three cases the client pays for the additional work not the service provider. paying by the hour is a poor and dated way to do business I differ on that opinion as well Sitepoint does too, almost all of the top talent in any development field works by the hour not by the project. Most know to not take the entrepreneurial risk of another company while engaging in a contract that limits their reward. http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing-vs-hourly-billing/ http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing-vs-h... You're selling a software solution to a client, so you should charge for that solution Right and if I am shouldering the risk of the development costs, I am going to license it to that company as well as there competitors. If they own the result of my labor then they pay for that labor. building software isn't an exact science and many projects overrun. and that is not the developers burden to bear. Scope creep is a reality with any novice firm who is looking for software development. A fixed bid set up an adversarial relationship immediately. You will constantly be parroting "out of scope" to the point that the client will be just as pissed as they would have been about cost overruns as they are about not getting the product they want. The knife cuts both ways, and the reality is more fixed bid projects fail, because at a certain point of losses the developer walks or the software gets shelved because the project as scoped is not what the client thought they wanted at the time of developing a functional specification. That's a fantastic way not to get hired for a project. It's really not, I educate my clients on the risks of software development and what they can do to limit scope creep, changes in priorities and politics, the three big killers of projects. Further all of my clients now are big tech firms, so they are well versus in these realities. Not allowing myself to into a bad deal in no way affects my ability to get projects. Coming off as an amateur in contract negotiations can hurt far more than being firm on how you structure your work. because you're the expert and you'll have the better idea of how long it should take. Unless you are a politician, there is no way that you can do this with any accuracy, the client will creep scope, it is a given, with time and materials you have a lever that you can pull to say OK we can add it, but it is going to affect you budget by X and your delivery by Y. It puts the onus on them to control scope creep, if it is on you, you will be strong armed into accepting it. If you don't they are just as mad as cost overruns and you have received no money, so when they pull the plug you are the one left holding the bag. I have been doing this for 20 years and have seen first hand that fixed bids cause more problems for both sides. Take a look at all the top guys on HN, take a look at there stories as to why they only do time and materials, each and every one of them will have a fixed big horror story.

by EnderMB 16y ago

kls 16y ago

The best thing to do in this instance is to find out their overall budget for this thing, break it down into an hourly wage and set an overall price based on what you feel your time is worth. A Mechanic does not fix you car based on a total cost, they charge a hourly labor rate + parts. A lawyer bills for his services by the hour. Both will provide a best guess at what they think it will take, but if you add some work or they find some problems you eat that cost not them. Why people think software development should be any different is beyond me. If you are not getting equity in the project then you should not be working on a fixed price contract. It places all the risk on you while limiting your upside (you can only make the sticker price on the contract). Meanwhile the client has unlimited upside in this arrangement and shoulders none of the risk beyond the sticker price. the employer will feel cheated if paying for longer than they expect (and let's be honest, all employers think that websites take half the time to build). Ignorance of the discipline of software development is the employer problem, a good software developer can show them how scope creep, change in priorities and adjustments to specification has a negative impact on their expectations. If they feel cheated that is their problem to deal with, software development is not charity and if it takes twice as long to build and a developer puts in twice as many hours then they should be paid twice the hours just as any other service professional is. The client/employer is not going to say "oh wow we made twice as much as we expected off the software you developed, here you go, here is some free money". So why would the developer say "oh wow the project will take twice a long as, the employers uneducated analysis says it will, let me eat half the labor costs" That being said, only extremely experienced freelancers should consider taking a fixed price contract. It can lead to financial ruin, in almost all situations a freelancer should be insisting on time and materials, like 90% of other service professionals. The exceptions would be reproducible services where times can be estimated with certainty (e.g installing wordpress or Postgres). To answer the parent posters question, I see a lot of Senior level JavaScript freelancers charging in the area of $100-$200 hr for their services. That is what I charge and stay busy.

EnderMB 16y ago
> A Mechanic does not fix you car based on a total cost, they charge a hourly labor rate + parts. A lawyer bills for his services by the hour. Both will provide a best guess at what they think it will take, but if you add some work or they find some problems you eat that cost not them. You're not a Lawyer or a Mechanic, you're (possibly) a Web Developer and it's fairly standard to charge based on project, as referenced by countless guides, online resources and notably within SitePoint's Web Design Business Kit. I've already stated the reasons why you do this, because it confirms the overall cost with the client, it ensures the project will not overrun at the clients expense, and in the end the client has an overall budget for this work, not a certain amount to spend per hour. As time has shown, paying by the hour is a poor and dated way to do business on the web because building software isn't an exact science and many projects overrun. In the same vein I cannot understand why people have to treat software development as a "profession" like Lawyers or Doctors. You're selling a software solution to a client, so you should charge for that solution, in the same way that people who offer products or solutions charge. > Ignorance of the discipline of software development is the employer problem, a good software developer can show them how scope creep, change in priorities and adjustments to specification has a negative impact on their expectations. If they feel cheated that is their problem to deal with, software development is not charity and if it takes twice as long to build and a developer puts in twice as many hours then they should be paid twice the hours just as any other service professional is. That's a fantastic way not to get hired for a project. It cannot be more simple than setting a price on your time per hour, estimating how long a project will take and charging what you feel your time is worth as a lump sum. The client should not get to dictate that, because you're the expert and you'll have the better idea of how long it should take.
- kls 16y ago
  You're not a Lawyer or a Mechanic The nature of the arrangement is more similar that not. Both do project based work as service professionals. And both have unforeseen variables that cannot be known at the time of estimating. Lawyers routinely deal with unforeseen political issue (ruling not going the way they expected) and mechanics routinely deal with unforeseen problems that are technical in nature (mechanical failure, that was not known until the heads where pulled off). Software developers routinely deal with both natures of unforeseen variables in addition to the client adding work after the estimate. Which would be akin to a mechanic giving someone a quote and then when they are half way through the project the client saying well while you are in there go ahead and change out the pistons for forged steel ones, and then arguing because the client got charged for the parts and labor. In all three cases the client pays for the additional work not the service provider. paying by the hour is a poor and dated way to do business I differ on that opinion as well Sitepoint does too, almost all of the top talent in any development field works by the hour not by the project. Most know to not take the entrepreneurial risk of another company while engaging in a contract that limits their reward. http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing-vs-hourly-billing/ http://blogs.sitepoint.com/2010/09/14/flat-rate-pricing-vs-h... You're selling a software solution to a client, so you should charge for that solution Right and if I am shouldering the risk of the development costs, I am going to license it to that company as well as there competitors. If they own the result of my labor then they pay for that labor. building software isn't an exact science and many projects overrun. and that is not the developers burden to bear. Scope creep is a reality with any novice firm who is looking for software development. A fixed bid set up an adversarial relationship immediately. You will constantly be parroting "out of scope" to the point that the client will be just as pissed as they would have been about cost overruns as they are about not getting the product they want. The knife cuts both ways, and the reality is more fixed bid projects fail, because at a certain point of losses the developer walks or the software gets shelved because the project as scoped is not what the client thought they wanted at the time of developing a functional specification. That's a fantastic way not to get hired for a project. It's really not, I educate my clients on the risks of software development and what they can do to limit scope creep, changes in priorities and politics, the three big killers of projects. Further all of my clients now are big tech firms, so they are well versus in these realities. Not allowing myself to into a bad deal in no way affects my ability to get projects. Coming off as an amateur in contract negotiations can hurt far more than being firm on how you structure your work. because you're the expert and you'll have the better idea of how long it should take. Unless you are a politician, there is no way that you can do this with any accuracy, the client will creep scope, it is a given, with time and materials you have a lever that you can pull to say OK we can add it, but it is going to affect you budget by X and your delivery by Y. It puts the onus on them to control scope creep, if it is on you, you will be strong armed into accepting it. If you don't they are just as mad as cost overruns and you have received no money, so when they pull the plug you are the one left holding the bag. I have been doing this for 20 years and have seen first hand that fixed bids cause more problems for both sides. Take a look at all the top guys on HN, take a look at there stories as to why they only do time and materials, each and every one of them will have a fixed big horror story.