How to price a fixed-bid project without losing money

To price a fixed-bid project: break the scope into tasks, estimate each one as an hour range, price off the high end of the total, then add a risk buffer of 15-30% depending on how much you trust the scope. A fixed price means you carry the risk instead of the client - and the price has to include the cost of carrying it.

That is the whole method. The rest of this guide is how to do each step without fooling yourself, and a worked example with real numbers.

Why fixed bids go wrong

Fixed bids fail in a predictable way. Someone estimates the project as a single optimistic number, a discount gets applied to win the deal, and the scope was never written down precisely enough to say no to anything. Each step feels reasonable; together they guarantee that the project only makes money if nothing surprises you. Software surprises you.

None of that makes fixed bids a bad idea. Clients like them for good reasons - a known cost is easier to budget and easier to get approved. You just have to price them as what they are: a transfer of risk from the client to you.

The method, step by step

1. Fix the scope in writing

A fixed price for a loose scope is a blank cheque written by you. Before any pricing, get the scope into a task-level list specific enough that a stranger could tell whether a given request is inside it or not. “Admin area” is not scope; “admin can list, search and deactivate users” is.

Just as important, write the assumptions and exclusions: the client provides content, the third-party API works as documented, two revision rounds are included, anything not listed is not included. This section does more to protect a fixed bid than any buffer.

2. Break the work into tasks and estimate ranges

Split the project into tasks of roughly half a day to three days each, grouped by phase or area, and give every task a low and a high number - “12 to 20 hours”, not “16”. The high number is not padding. It is what the task costs when the normal things go wrong: the API that does not behave, the design that needs a third round.

Do this with the people who will build it, not alone the night the proposal is due. If you want a starting structure, there are six worked templates with pre-estimated task breakdowns for common agency projects, and a guide to what a software estimate needs.

3. Price off the high end

Sum the ranges and multiply the high total by your hourly rate. This is the step most people flinch at, so it is worth being precise about why it is right: on time and materials, the client pays the actual hours wherever they land in the range. On a fixed bid, you have promised the price no matter where they land. The high end is not pessimism - it is the only end of the range you can commit to without betting the margin on luck.

4. Add a risk buffer

On top of the high-end price, add 15-30% for what the estimate cannot see: the requirement nobody mentioned, the integration that behaves differently in production, the week of back-and-forth over something small. Well-understood scope with a known client sits near 15%; vague scope, new territory or a new client pushes toward 30%.

If you catch yourself wanting more than 30%, listen to that instinct - it is telling you the scope is not solid enough to fix a price on. Run discovery on time and materials first, then bid the build.

5. Agree the change process and the payment schedule

Two contract points that decide whether the pricing survives contact with the project. First, changes: anything outside the written scope gets estimated, approved and priced before it is built - routinely and without drama, because the process was agreed on day one. Second, payment: never a single invoice at the end. A deposit up front and milestones tied to delivery keep the cash flow sane and the client engaged.

A worked example

Say an agency is bidding a custom WordPress marketing site (here is the full template for one). After scoping with the client, the task ranges add up to 180-260 hours, and the agency bills €75/hour.

• On time and materials this project would invoice €13,500-19,500.
• Fixed bid: price off the high end - 260 × €75 = €19,500.
• The scope is fairly tight but the client is new, so add 15%: €22,425, rounded to a clean €22,500.

Now look at how that price behaves. If the project lands mid-range at 220 hours, the effective rate is about €102/hour - that surplus is what pays for the other project, the one that overruns. If it hits the top of the range at 260 hours, you are at €86/hour: still healthy. Even at 300 hours - past the high end of the estimate - you are at €75/hour, breaking even at your normal rate on a project that went wrong. The buffer did not make the project expensive; it made the worst realistic case survivable.

Compare the usual alternative: bid the midpoint, 220 × €75 = €16,500, then shave 10% to win the deal. At the same 260 actual hours that is €57/hour - a 24% pay cut you signed up for in advance, and nobody even asked for it.

Mistakes that turn a fixed bid into a loss

• Pricing the optimistic end to win the work. You are not winning a project, you are buying one.
• Estimating alone. The proposal writer’s guess about the integration is not the integrator’s.
• Leaving scope verbal. Every undocumented “obviously it includes X” will be resolved in the client’s favour, at your cost.
• Treating change requests as favours. Each free “small change” re-prices the project downward. The change process exists to be used.
• One invoice at the end. You are not a bank; do not finance the project interest-free for its whole duration.

A fixed bid priced this way is nothing exotic - an honest range estimate, priced from the end you can actually commit to, with the risk you are taking written into the number. Get the estimate right and the price mostly takes care of itself.

Frequently asked questions

How big should the risk buffer be on a fixed-bid project?

Between 15% and 30% on top of the high end of your estimate, depending on how well the scope is understood. Use the low end for well-specified work you have done before, the high end for vague scope, new technology, or a client you have never worked with. If you feel the project needs more than 30%, that is a sign it should not be fixed-bid at all.

What should I do when the client says the fixed price is too expensive?

Cut scope, not price. Reducing the price while keeping the scope means you have silently agreed to absorb the difference. A task-level estimate makes the scope conversation easy: show the breakdown, ask which parts can wait for phase two, and re-price the smaller project.

When is time and materials better than a fixed bid?

When the scope cannot be pinned down - early product work, ongoing development, anything research-shaped. A fixed bid prices risk, and unbounded scope is unbounded risk. Many teams run discovery on time and materials, then fix the price for the build once the unknowns are gone.

Can the price change after a fixed-bid contract is signed?

Only through the change process you agreed up front. That is not a loophole - it is the mechanism that keeps a fixed bid fair. The fixed price covers the written scope; when the client asks for something outside it, you estimate the change, they approve it, and the price moves. Without that process, the price is fixed but your costs are not.