What does a software build cost estimate actually contain?

An estimate is a set of assumptions about scope, uncertainty, and time, translated into a number. The number itself is the output of those assumptions, so the most important question is not whether the number is right but whether the assumptions behind it are. An estimate from someone who understands the full scope of the work and the specific risks involved is more useful than a low estimate from someone who scoped narrowly or priced without accounting for the hard parts.

Why do software estimates turn out to be wrong?

Estimates are wrong when the scope changes, when the hidden complexity of the work is discovered during the build, or when the assumptions the estimator made turn out not to match reality. Scope is the most common cause: an estimate scoped to the visible features misses the integration work, the data migration, the edge cases, and the operational setup. Those are often larger than the visible features themselves.

How do you tell if an estimate covers the full scope?

Ask the estimator to list what is included and what is not. Specifically: does the estimate include data migration, integration with existing systems, the operational environment, testing, and launch support? A fixed-price estimate that covers the happy path of the visible features but excludes these categories is not an estimate for the whole project. It is an estimate for a part of it, presented as if it covers the whole thing.

What does a suspiciously low estimate usually mean?

It usually means one of three things: the estimator scoped narrowly and excluded the hard parts, the estimator has not done this kind of work before and does not know where the complexity is, or the estimate is a loss-leader price that will increase once work has started and switching costs are high. Ask the estimator to show their breakdown by work category. The breakdown will reveal which of the three you are looking at.

What does a surprisingly high estimate usually mean?

It may mean the estimator is accounting for risk you have not thought about, or it may mean they are padding for uncertainty they have not investigated. The productive response is to ask what is driving the high number, section by section. If the answer is "we are not sure about X, so we added contingency," the right next step is to investigate X rather than to accept the contingency or to find a cheaper estimate from someone who skipped the investigation.

What is a contingency line and when is it reasonable?

A contingency is an amount added to an estimate to account for risk or uncertainty the estimator cannot specify exactly. A contingency line is reasonable when the estimator can name the specific risks it covers and explain why the amount was chosen. A contingency that is a round percentage with no explanation attached is a padding number that tells you the estimator did not investigate the uncertainty. Ask what risks the contingency covers, specifically.

When should you ask for a breakdown of an estimate?

Always. An estimate without a breakdown is a number you cannot evaluate. The breakdown shows which categories of work the estimator thought about and which they did not. It shows where the time and cost assumptions are concentrated, which tells you where the risk is. A breakdown also makes it possible to have a productive conversation about scope: if the breakdown shows a large integration line, you can ask why integration is expensive on this project, and the answer will tell you something about the specific risks involved.

What is the difference between a fixed-price estimate and a time-and-materials estimate?

A fixed-price estimate commits the vendor to delivering the described scope for the named price. A time-and-materials estimate bills for actual hours worked at a named rate. Fixed price shifts the financial risk of scope uncertainty to the vendor. Time and materials shifts it to the client. Neither is better in general: fixed price works when the scope is well-defined before the work starts, and time and materials works when it is not. A fixed-price estimate on a poorly-defined scope is usually a promise the vendor cannot keep, which leads to scope disputes and change orders.

How do you use an estimate to negotiate scope rather than price?

Treat each line in the breakdown as a scope decision. If the total is higher than you can afford, ask which lines cover features or capabilities you could defer to a later phase. This is a more useful conversation than asking the vendor to cut their price, because it makes the tradeoff explicit: less scope for less cost, rather than the same scope at a lower margin. A vendor that cuts price without cutting scope is usually planning to cut quality or understaff the project.

How to read a build cost estimate you did not write: Reveneau

Q: How should you compare estimates from two different vendors?

Compare what each estimate includes, not the numbers. Two estimates for the same project can differ by a factor of three if one includes integration and testing and the other does not. Put the scope of each estimate side by side before you compare costs. If you cannot put the scopes side by side because one of the estimates does not break down what it covers, that is itself a warning sign about the estimator's approach.

A software build estimate is a number that summarizes a set of assumptions about scope, uncertainty, and time. The number matters, but it is the last thing to look at. The assumptions underneath it determine whether the number will hold, and reading an estimate means reading the assumptions, not comparing totals.

This is not how most people read estimates. The natural instinct is to look at the bottom line, compare it to the budget, and either approve or negotiate the price. The result is predictable: projects start, scope expands, the original estimate turns out to have been missing several large categories of work, and the final cost is higher than the original number by a wide margin.

Here is how to read an estimate so you can tell whether the assumptions behind it hold.

Start with what it includes

The first question to ask about any estimate is: what is explicitly included, and what is explicitly excluded?

A well-constructed estimate lists both. The included work tells you what the estimator thought about. The excluded work tells you what you will need to handle separately, either in a later phase, with a different vendor, or on your own. An estimate that lists only inclusions without naming exclusions is hiding the question.

The categories most commonly left out of estimates are: data migration from an existing system, integration with other software the new product needs to connect to, the operational environment where the product will run, the testing work beyond basic unit tests, and the support required during and after launch. Each of these can be a large piece of the total work. When all of them are absent from an estimate, the estimate is for the visible features only, presented as if it covers the whole project.

Ask the estimator directly: does this estimate cover integration with our existing systems? Does it cover data migration? Does it cover the work required to get this running in production? The answers will tell you which version of the project is being priced.

Ask for the breakdown

An estimate without a line-by-line breakdown is a number you cannot evaluate. The breakdown shows which categories of work the estimator thought about and which they did not. It shows where the time and cost are concentrated, which tells you where the risk is. It makes scope negotiation possible: if a line is large, you can ask what makes that category expensive, and the answer will tell you something specific about the work.

A breakdown also makes it possible to compare two estimates from different vendors without comparing the wrong things. Two estimates for the same project can differ by a factor of three if one includes integration and testing and the other does not. Comparing those totals without comparing the scope is not a useful comparison. Put the scope of each estimate side by side before you look at the numbers.

If a vendor declines to provide a breakdown, or provides one that is too aggregated to tell you anything, that is itself information about how they estimate work and how they expect to manage the project.

Understand what drives the number

The two most common reasons an estimate is wrong after the fact are scope changes and hidden complexity. Scope changes are partly avoidable: the more clearly you define what you need before the estimate is written, the less scope will expand later. Hidden complexity is harder to prevent, but a good estimate accounts for it rather than ignoring it.

When an estimate has a contingency line, ask what it covers. A contingency that names specific risks and explains the amount is a sign that the estimator investigated the uncertainty. A contingency that is a round percentage with no explanation is a padding number. These are different things.

A suspiciously low estimate usually means one of three things: the estimator scoped narrowly and excluded the hard parts, the estimator has not done this kind of work before and does not know where the complexity is, or the estimate is a low opening price that will increase once work has started. Ask the estimator to walk through the breakdown with you and explain the assumptions behind each major line. The explanation will reveal which of these you are dealing with.

A surprisingly high estimate may mean the estimator is accounting for risk you have not thought about. The productive response is to ask what is driving the number, section by section. If the answer is "we are uncertain about X," the right next step is to investigate X rather than to find a cheaper estimate from someone who did not investigate it.

Use the breakdown to negotiate scope

The most useful thing a detailed estimate enables is a scope negotiation rather than a price negotiation. Asking a vendor to cut their price without cutting scope usually produces one of two results: the vendor agrees and plans to cut quality or staffing to make the margin work, or the vendor disagrees and nothing changes.

Asking which lines in the breakdown cover work you could defer to a later phase is a different conversation. Each line is a scope decision. If you cannot afford the full estimate, the question is which parts of the scope you need immediately and which you can build after the first version ships. A vendor who can help you think through that question is more useful than a vendor who will simply cut a number.

This conversation requires a breakdown. Without one, there is nothing to negotiate other than the total.

Check the assumptions against your own knowledge

An estimate is the estimator's model of your project. You have knowledge they may not have, about your existing systems, your team's capacity, your deadlines, and your tolerance for scope risk. Reading the estimate means checking their model against yours.

If the estimate treats an integration as simple and you know the system being integrated is poorly documented and inconsistent, that is a mismatch worth raising before the work starts. If the estimate assumes a data migration can be done in two weeks and you know the data has years of accumulated inconsistencies, that assumption needs to be surfaced.

The estimate is a starting point for alignment, not a final answer. The goal of reading it is to find the gaps between the estimator's model and reality, so they can be addressed before the gap becomes a scope dispute in the middle of a build.

How to read a build cost estimate you did not write