Most software estimates fail before a line of code is written, not because the arithmetic is wrong but because the estimate hides what it does not know. A single figure on a slide, say “$420,000 and six months,” looks precise and reassuring. It says nothing about the assumptions behind it, the risks that could double it or the decisions that would shrink it. When reality arrives, both sides feel misled.
A good estimate is a communication tool, not a prophecy. It should explain what is being built, how confident the estimator is, what could change the number and what will be done to reduce uncertainty. This article sets out what a credible software estimate should contain in 2026, why ranges are more honest than single numbers, how a discovery phase earns its cost, how AI coding tools change the picture, and how to compare quotes from different vendors without being fooled by the lowest figure.
Why Single-Number Estimates Mislead
Early in a project, almost everything that drives effort is still undecided: the exact features, the user experience, the integrations, the data quality and even the team. Steve McConnell’s well-known Cone of Uncertainty, published by Construx, captures this. At the initial concept stage, skilled estimators can still be off by a factor of four in either direction, a sixteenfold total range. Even after the product definition is approved, the error band is two to four times. McConnell describes these as best-case accuracy for skilled estimators; poorly controlled projects can do worse.
Two further points from that work are often missed. First, the cone narrows only when decisions remove variability, such as agreeing what is out of scope, completing requirements or settling the user interface. Time passing does not narrow it. Second, if a project never drives out those decisions, uncertainty persists to the end, which McConnell calls a cloud rather than a cone.
There is also the shape of the risk. A 2022 study by Bent Flyvbjerg and colleagues of 5,392 IT projects found that cost overruns follow a fat-tailed, power-law distribution rather than a normal curve: most projects overrun modestly, but a minority overrun dramatically, far more often than a bell-curve mindset would predict. The authors link this to interdependencies between technology components, where a problem in one part cascades into others. The practical lesson is that an estimate should talk explicitly about tail risks, not just a most-likely figure.
An estimate is not a promise of a number. It is an explanation of what is known, what is assumed, what could go wrong and how uncertainty will be reduced.
The Anatomy of a Credible Estimate
Whether it comes from an internal team or an outside vendor, a trustworthy estimate should cover at least the following elements.
1. Scope, in and out
A clear description of what is included, expressed as features, user journeys or outcomes, and just as importantly what is excluded. Out-of-scope statements prevent the most common dispute: each side assuming the other understood something that was never written down.
2. A range with a confidence level
For example: “We expect 22 to 30 weeks of team effort, with roughly 80% confidence of landing within that range given the stated assumptions.” Three-point estimating (optimistic, most likely, pessimistic) for each work package is a simple way to build this, and it makes the uncertain packages visible.
3. Explicit assumptions
Every estimate rests on assumptions: that APIs are documented and stable, that test data will be available, that a product owner will make decisions within days, that the existing system can be accessed. Listing them turns hidden risks into checkable facts and gives both sides a fair basis for change control when an assumption proves false.
4. A risk register
The main risks, their likelihood, their potential impact on cost and schedule, and the planned mitigation. Good estimates distinguish between risks covered by contingency and risks that would trigger a re-estimate.
5. Team, roles and timeline
Who will do the work, the seniority mix, how many people at each phase and the calendar this implies. Effort and duration are different: four people for six months is not the same as eight people for three months, because coordination costs grow with team size.
6. Method and basis
How the estimate was produced: bottom-up from work packages, by analogy with past projects, by parametric models, or a combination. Estimates built in more than one way, and reconciled, are more reliable than a single approach.
7. What is not in the number
Licenses, cloud hosting, third-party services, data migration, training, hypercare after go-live and ongoing support are often left out or buried. A good estimate lists them, even if only to say they are priced separately.
Assumptions and Risks Worth Spelling Out
Certain assumptions recur across software projects and deserve particular attention because they cause the largest surprises when they fail:
- Integration readiness: third-party and internal APIs exist, are documented and have test environments.
- Data quality: source data is clean enough to migrate or analyze without major remediation.
- Decision speed: the client can review work and make product decisions within an agreed turnaround time.
- Environment access: development, test and production access is granted early, with the necessary security approvals.
- Non-functional requirements: performance, availability, security and accessibility targets are known and realistic.
- Regulatory constraints: compliance obligations (privacy, accessibility, sector rules) are identified up front, not discovered in user acceptance testing.
- Legacy behavior: undocumented rules in existing systems have been, or will be, captured before they are reimplemented.
Each of these can be turned into a risk with a mitigation, such as a spike to test an integration, a data profiling exercise or an early security review. The goal is not to eliminate uncertainty in the document but to show that it is understood and managed.
Discovery: Paying to Narrow the Range
If early estimates carry a fourfold error in either direction, it makes little sense to sign a large fixed commitment at that point. A short, paid discovery phase is the usual remedy. The UK Government Digital Service’s service manual offers a well-tested template: discovery is for understanding the problem, users and constraints before committing to build, typically takes around four to eight weeks, and explicitly should not start building the service. Its guidance also makes the point that stopping after discovery is not a failure; it can save significant time and money.
For a commercial software project, a good discovery typically produces:
- A validated problem statement and measurable success criteria.
- User journeys and a prioritized feature map, with a clearly marked minimum viable scope.
- An integration and data inventory, with the riskiest items tested through technical spikes.
- A target architecture and key technology decisions.
- A refined estimate with a narrower range, updated assumptions and a risk register.
- A delivery plan: team shape, phases, milestones and the engagement model that fits.
In McConnell’s terms, discovery is where the decisions that narrow the cone get made. Paying for it is paying to convert unknowns into knowns before the expensive part begins.
How AI Changes Software Estimation in 2026
AI coding assistants and agents are now mainstream. Google’s 2025 DORA report found that 90% of surveyed technology professionals use AI in their work. That raises a fair question from buyers: should estimates be smaller now?
The honest answer is: for some work, yes; for other work, not much; and the estimate should say which is which.
- Work that compresses well: boilerplate code, CRUD screens, test scaffolding, documentation, data mapping, and migrations between similar frameworks.
- Work that compresses little: product discovery, complex integrations, ambiguous requirements, performance and security engineering, and changes in large, poorly tested legacy codebases.
- Work that may grow: code review, verification and test design, because generated code must still be checked and “almost right” output is a common failure mode.
Controlled evidence is still mixed. METR’s randomized trial in early 2025 found experienced developers working in large, mature repositories took 19% longer with AI tools, despite believing they were faster; in early 2026 METR said it believes developers are now more sped up but that its newer data is weak evidence of the size of the gain. The lesson for estimates is to treat AI productivity as an assumption to state and verify in the first sprints, not as a blanket discount applied to every line item.
A well-written 2026 estimate therefore states how AI tooling is used, which work packages assume AI acceleration, what engineering foundations (tests, pipelines, clean architecture) that acceleration depends on, and how the estimate will be recalibrated once actual velocity is observed.
How to Compare Vendor Quotes Fairly
Comparing quotes is hard because vendors rarely price the same thing. A lower number often means a narrower scope, more optimistic assumptions or more risk pushed back onto the buyer. Use the following steps to compare like with like.
- Give every vendor the same brief. Include goals, known scope, constraints, non-functional requirements and the questions you want answered. Ask for a standard response structure.
- Normalize scope. Build a simple matrix of features and deliverables and mark which each quote includes, excludes or leaves unclear. Hidden exclusions are the most common reason one quote is much cheaper.
- Compare assumptions side by side. A vendor assuming clean data and ready APIs will quote lower than one that has priced remediation. Neither is wrong; they are pricing different worlds.
- Compare ranges, not midpoints. Ask for optimistic, likely and pessimistic figures. A vendor unwilling to give a range is either very confident or has not thought about risk.
- Look at team composition. Seniority mix, named roles, QA and DevOps allocation, and who leads delivery. Thin QA is a common way to cut price and a common source of late surprises.
- Check what happens when assumptions break. Read the change-control process. A low fixed price with aggressive change requests can cost more than a higher, more realistic one.
- Ask how AI is reflected. Which tasks are assumed to be accelerated, how quality is assured and who benefits if delivery is faster than planned.
- Probe with scenarios. Ask each vendor how their estimate changes if a key integration slips by a month or a new compliance requirement appears. The quality of the answer reveals the quality of the thinking.
Red flags in a quote
- A single precise number with no range or confidence statement.
- No assumptions or exclusions listed.
- A timeline that does not match the team size or seniority proposed.
- No allowance for testing, deployment, documentation or hypercare.
- A price that drops sharply when you push back, without any change in scope or assumptions.
Worked Example: Two Quotes for a Customer Portal
Imagine a generic B2B distributor seeking quotes for a customer self-service portal: order tracking, invoices, returns and integration with its ERP and CRM.
Vendor A quotes $280,000 over five months, fixed price. Vendor B quotes $340,000 to $430,000 over six to eight months, recommending a five-week discovery first. At a glance, Vendor A looks cheaper and faster.
Normalizing the quotes changes the picture. Vendor A assumes the ERP exposes documented REST APIs, excludes data migration of historical invoices, budgets one part-time tester and treats any integration change as a paid change request. Vendor B has discovered, from a short pre-sales call, that the ERP integration may require middleware, prices historical invoice migration, includes a full-time QA automation engineer and two weeks of hypercare, and states that its range assumes AI-assisted development for portal screens but not for integration work.
When the distributor checks, the ERP has only partial APIs. Under Vendor A’s terms, that would trigger change requests likely to push the real cost toward or beyond Vendor B’s midpoint, with less testing and no migration. The distributor commissions Vendor B’s discovery, which confirms the middleware need, narrows the build estimate to a tighter range and identifies a smaller first release that delivers order tracking and invoices sooner. The cheapest headline number was never the cheapest outcome.
Keeping the Estimate Alive During Delivery
An estimate should not be filed away once the contract is signed. Treat it as a forecast that improves with evidence:
- Re-forecast regularly, for example every few sprints, using actual velocity rather than the original assumptions.
- Track assumptions as risks: mark each as confirmed, broken or still open, and adjust the forecast when one breaks.
- Burn down contingency visibly, so both sides see how much buffer remains.
- Re-estimate when scope changes, not just when the budget runs low.
- Compare plan and actuals at milestones and feed the lessons into future estimates, which is how organizations build their own reference data.
This rolling approach also makes AI assumptions testable. If the team assumed significant acceleration on screen development, the first two or three sprints will show whether that holds, and the forecast can be adjusted early rather than at the end.
Conclusion: Ask for the Explanation, Not Just the Number
A credible software estimate explains scope and exclusions, gives a range with a confidence level, lists assumptions and risks, shows the team and method behind it, and states what is outside the number. In 2026 it should also explain how AI tooling is reflected and how that assumption will be checked. When the uncertainty is high, a short discovery phase is the cheapest way to narrow the range before making a large commitment.
When comparing vendors, normalize scope and assumptions before comparing prices, and favor the partner whose estimate shows the clearest thinking about risk. The best estimate is not the lowest or the most precise; it is the one that tells you the most about what could happen and what will be done about it.
How Hanoi Technology Can Help
Hanoi Technology provides ranged, assumption-based estimates and paid discovery phases so clients can make confident decisions before committing to a build.
Further Reading
- The Cone of Uncertainty – Construx (Steve McConnell)
- Study of Cost Overruns in 5,392 IT Projects – arXiv (Flyvbjerg et al.)
- How the Discovery Phase Works – GOV.UK Service Manual
- How Are Developers Using AI? Inside Our 2025 DORA Report – Google
- AI Coding Tools Can Slow Down Seasoned Developers by 19% – InfoWorld