I am relatively new to web development and haven't had to provide estimates for many large projects yet (my last large project was just paid for by the hour without a strict deadline or budget).

A client is asking me to provide a cost and time estimate for providing a myriad of changes to another developers code for a website (php/mysql backend).

Can anyone provide some advice or links on how to go about analyzing and estimating this? The code is horrible (the website was originally outsourced to india years and years ago) and it's hard to know if I'm going to suddenly hit hurdles and blow my estimates out of the water.


I think you should not name a price from the beginning. If someone talks to you about a project, you should do enough work for free to figure out what the client wants and how much it might cost. No more or less than that.

Give them a proposal, which can be extremely brief, but give them something that describes what they want and what you will deliver. You can put a range if you want, and you could even say that this is a “good faith estimate” but that the final amount will be based on time spent.

From my experience as a freelancer, there are 3 main steps in doing this:

  1. ask for 50% downpayment to begin work

  2. ask for final payment before handing over the files

  3. ask for a block of hours for ongoing work or work that will probably pop up over time

Good Luck!

| improve this answer | |
  • 3
    4. Stick to your guns when the client tries to push back. 5. Be prepared to walk away. – tzerb May 5 '12 at 21:10
  • ask for 50% downpayment to begin work... hm, isn't that a bit high? I would rather say 20% – šljaker May 5 '12 at 22:19
  • I think that 50% of the final payment would be the best amount to ask the client for. This way, he will not be tempted to ask some other programmer to do his job (half of the money is quite a lot to waste, isn't it? whereas a small percent is easier to be given up) and he will be stuck with you to the end of it. – appoll May 6 '12 at 10:18

Ask for an hourly rate. Don't let a lot of hours build up before you invoice.

| improve this answer | |
  • Yes. "Don't let a lot of hours build up..." – Dynamic May 25 '12 at 10:23

Go Agile! Don't estimate a whole bunch, especially if you don't have much experience under your belt.

  • Talk to your client and see what needs to be implemented/delivered.
  • For every functionality/unit-of-work create a user story (non technical part, write proper description) and break it into one or more subtasks (technical part)
  • Estimate every user story

Remember, estimate by its definition is always wrong, otherwise it would be called a number! It's very important that your client understands this as well!

You should do incremental delivery. Tell the client to prioritize user stories and select those to be delivered in the first iteration. Each iteration should last 2 weeks or less, but no more than 3 weeks! When you finish a user story (all its subtasks are closed), notify the client and ask him to verify it while you're working on the next user story.

You don't have to charge upfront, you can do it after each iteration.

Happy coding!

| improve this answer | |

Since you are new to the relevant technology and unfamiliar with the existing poor-quality code base you will be required to work on, it is likely that the estimation may vary to some extent in both directions. But let the client know about the latter reason :-P

First, list the myriad of changes/features your client has asked. For each requirement, do a little code review and research about how to implement and test it. You should invest this time without return before giving an estimate.

Second, make 3 columns for estimation - best case (25% probability), average case (50%), worst case (75%). For the 2 reasons mentioned in the first paragraph, you may choose the worst case estimation. You may then add even 20% buffer time. For example, for a particular requirement, your best case estimation is 2 days, average case is 4 days and worst case is 5 days. Adding 20% buffer time, your estimation is 6 days.

Third, do not give a fixed point of estimation, rather a range. For the above example, you can tell the client that the estimation is 4 to 6 days. Your client may insist on estimation for whole list of changes. In that case, you may add up the minimums and maximums of ranges for all requirements. Then provide a final estimation in range, say 5 to 6.5 months. This has the following advantage: you may exceed estimation for one requirement, but may finish another requirement earlier. In total, they cancel out each other and final estimation holds up.

Fourth, as you finish each user requirement and deliver incrementally, review your previous estimations for each requirement. This is a continuous process and you should adjust/refine the estimation as you proceed with the project and your experience grows. If you see that difference between your refined estimation and your initial estimation is out of control, sit with your client immediately and discuss the matter.

I learned these things from the book "Software Estimation : Demystifying the Black Art" by Steve McConnell. I am grateful to him.

| improve this answer | |

You could quote a total based on the estimated hours of work, clarifying your assumptions and the fact that any additional time required will be added on. This way if you go under (unlikely) you come out ahead.

Make sure the quality of existing code is clear to the client. If they are reasonable they should be accommodating to the flexibility, otherwise be prepared to walk away.

I was in this situation when I started out and unfortunately Stack Exchange did not exist at that time. I quoted a fixed price and had to bail on the deal two months in. I lost the money and burned a bridge since I could not deliver.

| improve this answer | |

Look to how similar industries do it. An architect wouldn't give an accurate estimate on a garage extension without having seen the property first.

Charge them an investigation fee for your initial time. Explain that the code is in a state where you can't possibly give them an accurate estimate without looking deeper at the current situation. Make sure they get something at the end of it, as a mark of faith, some documentation they could give to another developer if they chose to, to save them having to do the same work.

And then, if it's important to you that you get the actual development work, tell them that if they come to you for the actual development work, you'll knock 50% or even 100% of that charge off the final bill. You can't lose and people do so like to get something for free.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.