A lot depends on whether you're billing "time and materials" or whether there is going to be an agreed fixed price for the contract. For the second one, you have to have a pretty rigid specification in order to start - a list of all the screens and menus in an application as "wireframes", for example, with a brief description of what they do. Once you have that you can then assign some sort of average time cost to the features to produce a headline price.
Ask HN: Developers, how do you estimate projects and write proposals?
11–20 of 109 posts
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#12I generally believe that stating your hourly rate and providing frequent updates and milestones is a much better practice than giving an up-front project cost. Software dev is a very difficult task to estimate. Giving an up-front project cost is either pushing uncompensated risk onto the developer, or overcharging the customer for hours of work that may not occur, depending on how tough the project turns out to be on…
Do your clients accept that or is there push back? How do you bring them around to your (I think accurate) viewpoint?
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#13(about estimating - I don't tend to write proposals) You could have a look at https://www.estigator.com
(NB it's a half-finished side project right now)
I'm no longer a contractor, although I have been, and I'm frequently asked by my new employers to provide estimates for dev tasks.
Trouble is, businesses/clients tend to see an estimate as a promise, or a target. From the developer's point of view it is hard to do anything other than guessing (at smaller and smaller granularities). Book recommendation: "The Clean Coder" by Robert C. Martin - esp. Chapter 10)
I started building https://www.estigator.com to see if I could learn React, and come up with something to help me illustrate just exactly who's taking a risk when we say something like "it'll probably take about 3.5 days"
I wasn't quite ready to "Show HN" with this one, but your question made me think of it straight away. Would love to know what people think
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#14In my experience, providing effective estimates with actual data requires:
- know enough about what you are doing to estimate at all
- screening for clients who will make it possible to work effectively, and knowing how to do that
-setting realistic expectations about what can actually be accomplished
- the client has the resources to pay for the project, including multiple iterations of dealing with the unexpected
- you the resources to make efficient use of the clients resources
- you don't promise to deliver something that you quoted at a higher price when the client talks you down to a lower price
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#15Somewhat heretical, but I generally don't. I usually explain that development is an iterative process, and that I generally deliver work as soon as it's done. We talk about the knobs that are available to tune the work to the goal, and how to measure goals. We talk about containing costs, and working together to deliver good value. I find that in general, estimates are rarely, if ever, accurate to any significant deg…
This is the best way, especially if you are freelance and might carry some of the risk or a drop dead deadline.
If you do this, some people will work with you,
some people will not.
If you work with those people, this will not work.
Sadly
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#16Somewhat heretical, but I generally don't. I usually explain that development is an iterative process, and that I generally deliver work as soon as it's done. We talk about the knobs that are available to tune the work to the goal, and how to measure goals. We talk about containing costs, and working together to deliver good value. I find that in general, estimates are rarely, if ever, accurate to any significant deg…
> development is an iterative process, and that I generally deliver work as soon as it's done
You're kinda arguing against yourself. I agree that dev is an iterative process and that estimating is a lost cause, but "deliver work as soon as it's done"? The whole point is that a "done" project doesn't exist. Deliver all the time (every day, every week at worst), iterate and stop the project when the client is happy with what they have
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#17Break it down with clients as much as possible, tell them how long everything will take (don't worry overestimate just to be safe), then I explain software is not only about writing code so we have to add 20-40% for QA/itterations on top of estimated value.
But the thing is, it's only to estimate, I will never bill based on these estimations, just help to plan the client.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#18The problem with questions about estimation is that often the answers to the question come from a providing estimates to external customers standpoint. Providing estimates to things when you are building for internal use is much more complex as you have to consider politics, competition (internally) and often you have to estimate based on support from other teams who may not have the same priorities as you. Often too you have incomplete information and even incorrect information, your requirements may be sketchy and potentially no one actually knows what is needed or where it will go. That's incredibly difficult to manage and a different problem than providing estimates to a customer.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#19Somewhat heretical, but I generally don't. I usually explain that development is an iterative process, and that I generally deliver work as soon as it's done. We talk about the knobs that are available to tune the work to the goal, and how to measure goals. We talk about containing costs, and working together to deliver good value. I find that in general, estimates are rarely, if ever, accurate to any significant deg…
> development is an iterative process, and that I generally deliver work as soon as it's done You're kinda arguing against yourself. I agree that dev is an iterative process and that estimating is a lost cause, but "deliver work as soon as it's done"? The whole point is that a "done" project doesn't exist. Deliver all the time (every day, every week at worst), iterate and stop the project when the client is happy wit…
I really mean done as in "creates any positive change for the customer". Obviously if a file has syntax errors you don't push that to production. I usually do CI/CD really aggressively. Deliver as soon as the PR is approved or equivalent, assuming you have enough assurance in the form of test or qa. I would consider daily to be a little slow for my tastes.
Re: Ask HN: Developers, how do you estimate projects and write proposals?
#20I generally believe that stating your hourly rate and providing frequent updates and milestones is a much better practice than giving an up-front project cost. Software dev is a very difficult task to estimate. Giving an up-front project cost is either pushing uncompensated risk onto the developer, or overcharging the customer for hours of work that may not occur, depending on how tough the project turns out to be on…
I think upfront is better because you should be charging based on value. So what if something only takes you a few hours. If it generates enormous value for the client then you should capture a percentage of that value regardless of the cost to you. Likewise, if you underestimate then yes you eat the cost but you have a much happier client in the long-term. They don't feel cheated when you tell them it will take X more time, and you don't have to waste your time on time tracking and emails about why something takes 30 minutes.
I also try not to give estimates to clients. Rather I ask when their deadline is. If they have none, then I say I will give weekly updates.