Ask HN: Developers, how do you estimate projects and write proposals?

1). This is a new and unproven client, and if so, I go with the gut feel estimate e.g. 3 months, 2 weeks, 6 months to see if they understand how expensive software development (or any custom professional services) could be.

2). Understand if a rough or precise estimate is required. Are they looking for a fixed-price bid? Convince them that fixed-price is not in their interest. If the client insists on the fixed bid and the project is large and undefined, bow out. If the client is looking for a rough estimate, or the project is smallish (3). The client relationship is existing or the client and I are on the same page with the rough costing. If the project is large, explain that the estimation task is large and time-consuming, and ask to be compensated for the task. If the project is small (4). a). Gather understanding and very rough requirements over several meetings, and create a document capturing this information. b). Procrastinate and then break down larger system areas into "epics" c). Create a set of releases that each deliver value to the customer d). Estimate each "epic" and assign reasonably buffered estimate to each release. 5). Walk the customer over the document, timelines, budget estimates.

It would be really nice to be able to save the estimate to send to clients. Don't necessarily need backend for that - we can store data in the querystring for a fast & easy hack.

Even worse, they tend to treat the date/cost line as a promise, but the scope as infinitely flexible.

One other thing that makes me crazy is that a lot of places determine the date by a process that yields the first non-impossible date. (E.g., "Can this be done by Thanksgiving?" Developer yelps and says, "Well, maybe if everything goes right it could be done by Christmas." The PM responds, "Great! Christmas it is! I'll tell the CEO.") But if non-impossible means, say, 5% chance of success, then the developers look like goats 95% of the time.

These days, except with highly trusted partners, I basically refuse to estimate anything over 3 days without formal estimation and a self-calibrating process where any date is a function of product manager choices. (E.g., points, velocity, burndown.) But I find that less and less valuable, as interesting projects typically have requirements volatility too high to make dates actually predictable. Instead I prefer a release-early, release-often approach, hitting any non-artificial deadlines by being ready well in advance and iterating.

If you don't have a multiplier, expect to work overtime or divide your revenue.

As you get more comfortable with your estimates and your tools, you can reduce the value of that multiple. I've been able to get it down to 1.5x but the scope of the work was limited and our team was very familiar with the code.

As for the proposal document, there may be templates online. Some agencies create an exact list of features, and wireframes so that there is no scope creep. I recommend you do the same if you have time (some agencies with a good reputation bill for this work). Also, allow your client only two small changes to the design. Anything more, and it's extra money.

Your main problem with quoting will always be properly estimating the amount of work it takes to complete a project. The same project, with two different clients, may go from profitable to a loss. It's very important to pad the work and to gain a lot of experience in a small number of tools so that you may get better at estimating. Specialization is key.

You'll hear some people say that they bill iteratively. It's possible but not every client wants to hear that their project has an undefined cost. You'll still have to cap it at some value in which you can deliver the work.