Technically not my first, but my new client wants to enter into negotiations regarding the cost of a website.

It's fairly straight-forward, it's a little bit more than a portfolio page, and I should be able to finish it without much complications.

However, I don't know how to make an estimate to enter negotiations. One that will not scare the client away, and will ensure that I'm making the best out of it as well.


Charge by the hour. Seriously. You're new, it's a new-to-you client, and you don't have a large portfolio to ensure this task is "just like the other 100 you've done recently".

If you absolutely must offer up a fixed-price bid, make your best estimate of how many hours it will take, multiply that by the hourly rate you need, then add at least 30% to cover all the unexpected issues that will inevitably arise.*

If the bid is too high for the client, then the fix is to find another client - DON'T lower your bid unless you like making less per hour than your neighbor's babysitter.

Flat rate bids are for repetitive work - crank out a web site that's identical (except for font & color) to many others you've done.

Since it is necessary to negotiate, it's obvious this is not simple repetitive work.

@Michael's answer includes some excellent points about estimating - keep breaking up tasks into smaller sub tasks until no single task is more than xx hours long. I like to aim for 8, but sometimes miss.

  • 2
    +1 for charge by the hour.
    – Reactgular
    May 31 '13 at 16:37
  • Charge by hour is the only tried and tested way for this sort of projects where both sides walk happy at the end. I'd also like to sell that you can estimate how long it'd take and sell the client an hour bank . Be a tidy developer, keep neat version control and a bug tracker, these might be useful if a dispute over hours or progress ever arises. May 31 '13 at 20:51
  • If you want to know what hourly rate to charge use this: X is the salary you would like as a full time employee somewhere. Multiple X by 2. Next figure out how many days a year you want to work and divide X by those days. Finally divide the last result by 8 hours a day. I ended up at $104/hour. May 31 '13 at 22:14

In scenarios like this, I usually find it most helpful to take the project (e.g. website that functions as a portfolio page) and break it down into individual tasks.

For example:

  1. Front-end display
  2. Database schema
  3. Backend:
    1. User management
    2. Portfolio management
  4. Testing
  5. Bugfixing

Once the list is complete, I usually assign hour estimates to each. Borrowing from Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000245.html) and planning poker (http://www.planningpoker.com/), I try to keep these short. My rule of thumb, doubtless lifted from somewhere, is to keep all estimates below 32 hours and try to shoot for below 12. Anything larger needs to be broken up. I am firmly of the opinion that no one actually has any clue how long something estimated at over 40 hours will take.

Once you have done this, take your hour counts, sum them up and add some buffering. 10-20% usually seems pretty good. Also notice that testing and bugfixing are explicitly listed as tasks. I haven't always remembered to do it myself, but it is vital that they be included in estimates. You will wind up doing these things so include them in your estimates.

It is entirely possible that the resulting number will scare your client. Most clients have a poor intuition for how much work goes into development. What you do with this is up to you. I would remark that in my own experiences, failing to land a contract was not the worst thing to happen to me. Landing a contract that was not sustainable was. It created extra work, stress and a shortage of cash (even if only relative to the trouble).

  • 1
    +1 It created extra work, stress and a shortage of cash. very true.
    – Reactgular
    May 31 '13 at 16:42
  • what do you mean by "relative to the trouble"? I did not quite understand how shortage of cash related to the trouble of landing a stressful contract. Do you mean directly related as in mathematically direct correlation?
    – Dennis
    Mar 3 '16 at 16:18
  • Parts of it are subjective, like how much a given stress level is worth. Other parts can be quantified. For example, if the going rate for development in your area is $150 / hr and the estimate would give you the equivalent of $100 / hr, you may not be getting what you are worth even if you can strictly live off the income from $100 / hr. Bear in mind that there is a lot of time that goes into work with customers besides the coding. There is a lot of businessey stuff that goes on to maintain relationships and handle finances.
    – Michael
    Mar 3 '16 at 16:52

Part of how you approach the estimate is knowing how you intend or are expected to stay involved with the effort after the first pass of the work is completed. What degree of service or support do you intend to provide beyond the initial delivery during the revision or testing phases, and then again in the post-delivery phase?

The estimate for the first pass of the effort is a fixed cost. This estimate for the first pass is the time it takes to do those discreet, "clearly" defined tasks (scope) negotiated up front (statement of work). It is something you and only you know how long it might take since you were doing the work.

The subsequent passes will take the form of revisions, refinements, and late additions. This is where the customer explains that what you did is appreciated and quite nice, but not precisely what they want or need. This phase is highly variable, and so costing it out should eventually reflect that variability.

These subsequent passes can sparsely demand your time, or remain overwhelming for the near future. When the demands of a project are sparse, charging on a rate basis (by the hour, by the revision, by the additional feature complexity) makes sense for both parties involved. You can, without guilt, work on other things that may be more pressing. You may anticipate a minimum number of hours spent on this phase, and is often safe to do include some fixed period of time and cost for revision and refinement, and then move to a more variable cost after that pool of time initially set aside is exhausted.

Most efforts will involve both the initial cut and the later edits. The estimate should reflect and note the difference as it is in everyone's best interest.


  • Initial Cut: 40 dedicated hours, 25 hours committed per week ~ 8 business days
  • Expected Revision/Refinement: 15 dedicated hours, 3 hours per day ~ 5 business days
  • Total Allocated: 55 dedicated hours, 13 business days @ base_rate
  • Additional Revisions/Refinement: as needed and as available @ base_rate + some premium

Be sure to include some form of a statement of work with the cost figures (even if somewhat vague) so there isn't a big misunderstanding later about what was expected and what was delivered.

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .