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.

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).

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.

Example:

• 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.