How should we price a fixed-price project?

An agency quotes ₹18 lakh for a mobile app rebuild. The estimate behind it is 620 hours, the team is confident, and the client signs without much negotiation. Eleven months later the project has taken 890 hours, the fee has not moved, and the job earned about two thirds of the margin it was priced for.

Nobody was careless. The estimate was made honestly, the extra 270 hours were all real work, and most of them were things nobody thought to ask about at the quoting stage. That is the ordinary way fixed-price work goes wrong, and it goes wrong in the same direction almost every time.

A fixed price is not a pricing decision. It is a bet on the quality of your estimating, and the house edge belongs to whoever wrote the specification.

What a fixed price actually transfers

On time and materials work, if the job takes 40% longer, the client pays 40% more. The risk of being wrong about scope sits with them, which is why procurement teams dislike it.

On a fixed price, that risk moves to you entirely. The client gets certainty, which is worth something real to them, and you get the whole of the downside if the work is larger than either of you thought.

That trade can be a good one. Fixed prices win work, they are easier to approve internally at the client, and a firm that estimates well earns more per hour on them than it would have billed hourly. The trade only works if the price includes payment for carrying the risk, and most quotes do not.

If your fixed-price work earns the same margin as your hourly work, you are carrying the client's risk for free.

Build the number from hours, not from their budget

The most common way a fixed price goes wrong is that it starts from the wrong end. Someone mentions a budget, or a competitor's number is known, and the estimate gets worked backwards to fit it.

The order that works is the other one.

1. 01Break the work into pieces small enough that someone who would do them can estimate each in hours. If a piece is estimated at more than about 80 hours, it is not broken down enough to estimate.
2. 02Total the hours, by role, because a principal's hour and an analyst's hour cost very different amounts.
3. 03Cost them at fully loaded cost per billable hour, not salary divided by working hours. That means employer contributions, gratuity accrual, insurance and equipment in the numerator, and only sellable hours in the denominator.
4. 04Add the margin you intend the project to earn.
5. 05Add contingency, sized from evidence rather than feeling.
6. 06Only then compare the result to the client's budget, and decide whether to change the scope, decline, or accept a thinner margin with your eyes open.

That last step is where the discipline lives. There is nothing wrong with taking a project at a lower margin for a reason: a logo you want, a capability you are building, a client you expect to grow. There is a great deal wrong with doing it accidentally.

Contingency is not padding

Contingency has a bad reputation because it is usually applied as a round number that sounds prudent. Ten percent, because ten percent sounds careful.

It should be a measured figure. If your last twelve fixed-price projects came in an average of 22% over their estimates, your contingency is 22%, and it is not optional. It is the correction for a bias you have demonstrated twelve times.

Two things follow from treating it that way. The number usually turns out larger than the one people were comfortable with, which is uncomfortable and correct. And it falls over time as estimating improves, which gives the firm a reason to track its estimates properly.

It is worth separating two kinds of contingency. There is the correction for estimating error, which applies to everything and is the number above. And there is a specific allowance for a named risk on this project: an integration with a system nobody has seen, a client whose approvals are slow, a dependency on a third party. The first is arithmetic. The second is a judgement, and it should be written down next to the estimate so that the next person to quote something similar knows it was considered.

A worked example

Illustrative figures throughout. A firm estimates a project at 620 hours: 80 principal, 240 senior, 300 mid-level.

• ·Fully loaded cost per billable hour: ₹2,360 principal, ₹1,340 senior, ₹1,050 mid-level. So the delivery cost estimate is ₹188,800 plus ₹321,600 plus ₹315,000, or about ₹8.25 lakh.
• ·Target delivery margin of 50% means a price of about ₹16.5 lakh before contingency.
• ·The firm's last twelve fixed-price projects averaged 22% over estimate. Adding 22% to the hours, or equivalently to the cost, takes the delivery cost estimate to about ₹10.07 lakh and the price at the same margin to about ₹20.1 lakh.
• ·They quote ₹20 lakh. The client, who had ₹18 lakh in mind, negotiates. They agree ₹18.5 lakh with one module deferred, which takes about 60 hours out of the estimate.

Now play it forward. The project runs 21% over the reduced estimate, which is in line with history. Actual hours are about 678, delivery cost about ₹9.2 lakh, and the margin lands just above 50%. The firm made what it intended to make.

Compare that with the version where they quoted ₹16.5 lakh with no contingency, ran 21% over, and delivered at just under 40%. Same team, same estimate, same execution. The only difference is that one of them priced for the overrun they already knew was coming, and it was worth ten points of margin.

Where overruns actually come from

Three causes, and the fix is different for each, which is why lumping them together as 'the estimate was wrong' does not help.

Scope that grew

The work expanded beyond what was priced. This is the most common and the most fixable, and it is almost never a dispute. It is a series of small requests that nobody wanted to make a fuss about, each individually reasonable.

The fix is a change request process, however light. Not a contract negotiation each time: a short note saying what was asked for, what it adds in hours, and whether it is being absorbed or billed. Even when the answer is absorbed, writing it down changes the pattern, because the fourth one in a quarter becomes visible.

Estimates that were optimistic

The work was exactly what was priced and took longer. This is a systematic bias rather than a failure, and it is corrected with contingency and better decomposition rather than with a conversation.

One practical technique: ask the person who will do the work, not the person selling it, and ask for a range rather than a number. The top of their range is usually closer to the truth than the middle.

Waiting, rework and sequencing

The team was blocked on a client approval, an access request, a third-party dependency or a decision nobody made. The hours were spent, often on rework, and none of them moved the project forward.

This one is partly the client's doing, and it belongs in the contract rather than in the contingency. Name what you need from them and by when, and say what happens to the timeline and the price if it does not arrive.

What to put in the contract

• ·What is in scope, in enough detail that a disagreement can be settled by reading it. This is worth an extra hour at the quoting stage more than anything else on this list.
• ·What is explicitly out of scope. Shorter to write and more useful in practice, because it names the things the client assumed were included.
• ·The change request mechanism, and the rate at which additional work is charged.
• ·What you need from the client, by when, and the consequence if it is late.
• ·Milestone billing tied to delivery rather than to dates, so a client delay does not also become a cash delay for you.
• ·An assumptions list. Every estimate rests on assumptions, and writing down five of them converts a future argument into a change request.

None of this requires a heavier contract. Most of it is a page, and the page pays for itself the first time a client asks for something that was never discussed.

When not to quote a fixed price

Sometimes the honest answer is that the work cannot be estimated yet, and quoting anyway is just choosing to be wrong.

• ·The requirement is a paragraph rather than a specification. Price a discovery phase instead: a short, separately priced piece of work whose output is a specification and an estimate. Clients accept this far more readily than firms expect.
• ·The work depends on a system nobody has seen. Integrations with legacy internal tools are the classic case, and the range of possible effort is too wide to price.
• ·The client's decision-making is slow or unclear, and the timeline depends on their approvals.
• ·You have never done this kind of work before, in which case your estimating history does not apply and your contingency is a guess.
• ·The project is large enough that being 30% wrong would matter to the firm's year. Phase it, and price each phase when it can be specified.

Phasing is the underused answer to most of these. A discovery phase, then a priced build, then an optional second build, gives the client the certainty they wanted on each piece while never asking you to price something you cannot see.

Closing the loop

The difference between a firm that is good at fixed price and one that is not is almost entirely record keeping.

At the end of every fixed-price project, record four things: estimated hours, actual hours, the reason for any difference, and which of the three causes above it was. It takes ten minutes and it is the only way the next estimate gets better.

After a couple of quarters the record answers questions that guessing never will. Whether your overruns are scope or estimating, which kinds of project you estimate well, which client relationships consume hours nobody bills, and what your contingency should actually be. The project profitability tracker on this site is built to hold exactly that history, and the utilisation calculator shows what the hours cost in the first place.

It also tends to change the sales conversation. A firm that can say its fixed-price projects land within 5% of estimate has something worth saying, and it can charge for the certainty it is genuinely providing. That is the version of this where the risk transfer becomes a product rather than a liability.

About Simplify

Simplify is a finance clarity and investment readiness practice working with founders across India, built on six years inside startups. We write about the questions founders bring before a decision, not after it.