How Software Estimates Work and Why They Change

An estimate is a forecast made before most of the facts are known. Software project estimation goes wrong less often because someone counted badly and more often because a forecast was read as a price tag. Once you understand how the number is built, what the range around it means and what makes it move, you can plan around an estimate instead of being surprised by it.

This explainer is for the person approving the budget. It covers where the figures come from, the unknowns behind most changes, and how the type of contract decides who pays when reality differs from the plan.

What software project estimation is built from

Nobody can estimate "a booking system". A developer can estimate "a customer picks a time slot", "an admin blocks out holidays" and "a reminder email goes out the day before". So the first step is always to break the project into pieces small enough to compare with work the team has done before. Each piece gets a size, usually in hours or days.

Then comes the work that is not a feature and still has to happen:

• setting up the project, the servers and the release process;
• design, and the rounds of feedback on it;
• testing, and fixing what testing finds;
• project management, meetings and demos;
• moving data out of the old system;
• launch, and the support period right after it.

An estimate that lists only features and none of these should make you cautious. Finally the team adds an allowance for risk, sized to how much is still unknown.

Why an honest estimate is a range

"Between 300 and 420 hours" is more truthful than "352 hours". The second figure looks more professional and contains exactly the same uncertainty, only hidden.

Read a range like this. The low end is what the work costs if everything the team has assumed turns out to be true. The high end allows for the risks they can already see: an integration that may be awkward, a rule that may have exceptions. Neither end covers work that is not in the scope at all.

The range is widest at the start, when the project is a few paragraphs, and it narrows each time a decision is made: after requirements are written, after designs are approved, after the first risky piece is built. A team that gives you a tight figure from a one-page idea is either padding it heavily or guessing. Ask which.

The unknowns that move the number

Unknown	Why it changes the estimate	How to shrink it
Third-party systems	Documentation and real behavior differ, and test accounts take time to arrive	Get access early and build a small proof of concept
Existing code	A system nobody has opened in years may need updating before anything can be added	A code review before the estimate
Data to migrate	Old data has duplicates, gaps and formats nobody remembers	Share a real export, not a description
Business rules	The exceptions surface during the build	Write acceptance criteria for each feature
Design	Layouts decided late cause rework on screens already built	Approve wireframes before development
Decision-making	Several approvers with different views mean repeated rounds	Name one person with the final say
Quality targets	Speed under load, accessibility and security reviews are work in themselves	State them at the start
Outside approvals	App stores, payment providers and your own IT department keep their own calendars	Start those processes early

The "existing code" row deserves an example. A request to add one report to an older PHP application can turn into an upgrade project if the application runs on a PHP version that no longer receives security fixes (the PHP project lists which versions are still supported). Nobody could have priced that from the feature description alone.

Discovery buys accuracy

When the unknowns are large, the cheapest way to narrow the range is a short, separately priced discovery phase before the main estimate. A project manager, a designer and a developer spend that time with your team and produce:

• written requirements with acceptance criteria;
• wireframes of the main screens;
• a look inside any existing code and data;
• a quick technical trial of the riskiest integration;
• an estimate per milestone, with its assumptions listed.

You can take that package to any vendor, so it keeps its value even if you change teams. Skip discovery when the project is small and familiar, such as a standard website or a well-understood add-on. To do part of it yourself, start with a requirements document developers can use.

Fixed price or time and materials

The contract model decides who carries the risk that the estimate is wrong.

Fixed price

You agree a scope and a price, and the vendor absorbs any overrun inside that scope. In exchange, the scope has to be pinned down in detail before work starts, the price includes a buffer for the vendor's risk, and anything outside the written scope is a change request. It suits projects that are well defined and unlikely to change.

Time and materials

You pay for the hours worked at an agreed rate. You can change direction at any time and you pay for no risk buffer, but the total is not guaranteed. It suits products that will evolve as users react to them. To keep control, ask for a budget cap per milestone, regular reports of hours against the plan, and a demo of working software at short intervals.

Mixtures

Many projects combine the two: a fixed-price discovery followed by fixed-price milestones agreed one at a time, or a dedicated team working through a prioritized list. We compare the models in dedicated developer or fixed-price project.

Change requests are normal, so handle them in writing

Every project changes. You see the first working version and realize the approval step needs a second approver. That is the process working. Trouble starts when a change is agreed on a call, built without a figure attached and discovered on the invoice.

A workable routine has four steps: describe the change in a sentence or two, get its effect on cost and on the delivery date from the team, approve or decline it in writing, and only then let work begin. Often the best answer is a swap, where a new must-have replaces something of similar size that can wait.

It also helps to agree early on three words. A bug is the software not doing what the written requirement says, and fixing it is part of the price. A clarification fills in detail without adding work. A change adds or alters behavior. "Small" changes are frequently not small, because one new field can touch a form, a database table, three reports, an export, an email and the tests for all of them.

Reading and comparing estimates

When two estimates differ widely, the cheaper one has usually left something out. Before comparing totals, check that each one states:

• what is included beyond coding: design, testing, project management, deployment, data migration;
• what is excluded: content entry, third-party fees, hosting, support after launch;
• the assumptions it rests on ("the client provides API access before development starts");
• how many rounds of revisions are covered;
• what happens after launch, and for how long defects are fixed without charge.

Then ask each team: "What would make this figure go up?" A team that has thought about your project will answer with specifics like those in the table above. A team that says "nothing" has not.

Keeping your own estimate steady

A good part of what moves an estimate is in the client's hands. Appoint one decision-maker. Give feedback within the agreed time and in one consolidated list. Arrange access to systems, accounts and sample data before the build starts. Decide what is a must-have for launch, and defend that list against your own new ideas.

For a small, clear project, the checks above are enough to compare quotes without outside advice. For anything larger or less defined, start with a conversation and a discovery step, and treat the first figure as a range to be narrowed. That is how we quote custom software development: a free consultation and quote first, with milestones agreed in writing, and a dedicated team as the alternative when the scope will keep moving. You can request a quote with whatever you have written so far.

Frequently asked questions

Why do two companies quote very different amounts for the same project?

They are rarely quoting the same project. One assumed a simple version of a feature and the other a complete one, or one included testing, project management and migration and the other did not. Line the breakdowns up item by item and the gap usually explains itself.

Can a developer estimate from a one-page idea?

They can give a rough order of magnitude, which is useful for deciding whether the project is worth pursuing. Expect a wide range at that stage. A figure you can budget against needs written requirements and, for larger projects, a discovery phase.

Is the contingency in an estimate just padding?

No. It is an allowance for risks that are known to exist and cannot be sized yet, such as an integration nobody has tested. A team should be able to tell you what the allowance is for. On time and materials, you do not pay for it if the risks never occur.

Does a fixed price also fix the delivery date?

Only if the contract says so, and only for the agreed scope. Dates depend on your side as well: late feedback, late content or late access to systems push delivery back under any contract model. Ask for milestones with dates and the conditions they depend on.