"How much will it cost and when will it be ready?" are the first questions anyone asks about new software, and the hardest to answer well. Software project estimation is part craft, part arithmetic and part honesty about what is still unknown. Understanding how estimates are produced helps you read quotes critically, compare them fairly and avoid the most common budget surprises.
Why software is hard to estimate
Building a house is estimated from drawings, standard materials and known labour rates. Software has fewer standard parts: almost every project includes something that has not been built in exactly that way before. Uncertainty also comes from requirements that are still being discovered, integrations with systems whose behaviour is undocumented, and the simple fact that people learn what they want by seeing a first version.
For this reason experienced teams talk about the cone of uncertainty: estimates made at the idea stage can be off by a large factor, and they narrow as requirements, designs and early builds remove unknowns. An estimate is only as good as the information behind it.
Common software project estimation techniques
Expert judgement
An experienced developer or architect reviews the requirements and estimates from experience. It is quick and often reasonable for familiar work, but it depends heavily on the individual and can be optimistic.
Bottom-up (work breakdown)
The project is broken into small tasks, typically a few hours to a few days each, and each task is estimated. The totals are added up. This is the most detailed approach and the most reliable for well-defined scope, but it takes time and can miss work nobody thought to list, such as deployment, data migration or project management.
Analogous estimation
The new project is compared with similar past projects, adjusted for differences in size and complexity. It works well when a team has records of genuinely comparable work.
Three-point estimation
For each task the estimator gives three figures: optimistic, most likely and pessimistic. A common weighted average is (optimistic + 4 × most likely + pessimistic) ÷ 6. The spread between optimistic and pessimistic is as useful as the average, because it shows where the risk lies.
Relative estimation (story points)
Agile teams often estimate effort in story points, a relative measure of size and complexity rather than hours. After a few sprints, the team's average throughput (its velocity) converts the remaining backlog into a forecast. This approach becomes more accurate over time but is of limited use before any work has started.
What actually drives the cost
When two quotes differ widely, the gap usually comes from different assumptions about these factors:
- Number of user roles and screens. Each role multiplies permissions, views and testing.
- Business rules. Pricing logic, approval workflows and exception handling often hide most of the complexity.
- Integrations. Every external system adds effort, and older or poorly documented ones add more.
- Data migration. Moving and cleaning data from old systems is regularly underestimated.
- Non-functional requirements. High availability, strict security or heavy traffic need more design and infrastructure.
- Platforms. A web app, an iOS app and an Android app are not one product but three delivery targets, though cross-platform tools can reduce the gap.
- Design quality. A bespoke, polished interface costs more than a clean standard one.
- Testing, deployment and documentation. Responsible estimates include them explicitly.
Reading an estimate
A trustworthy estimate usually has these features:
- It is a range, or states its confidence. "Eight to eleven weeks" is more honest than "nine weeks".
- It lists assumptions. For example: "client provides all content", "payment gateway has a documented API", "single language".
- It shows a breakdown. You can see roughly how effort splits between features, design, testing and management.
- It names exclusions. Hosting costs, licences, ongoing support and app store fees are often outside the quote.
- It includes contingency. A buffer for unknowns is a sign of realism, not padding.
Be wary of an estimate produced within hours from a two-line brief with no stated assumptions. It may be accurate, but you have no way of knowing.
How to get better estimates
- Provide a written requirements document with priorities. The more you define, the narrower the range.
- Pay for a discovery phase on larger projects. A few weeks of analysis, design and technical investigation converts a rough guess into a reliable plan.
- Share constraints openly, including budget range and deadline, so suppliers can propose what fits.
- Ask about the biggest risks. A good team will tell you which parts of the estimate they are least sure about.
- Re-estimate as you go. Treat the estimate as a forecast to be updated, not a promise carved in stone.
Turning estimates into a budget
An estimate covers development effort. Your budget also needs room for hosting and third-party services, your own staff's time on testing and decisions, training, and support after launch. Ongoing maintenance is a real cost; plan for it from the start rather than discovering it in year two. For cloud costs, it is worth getting separate advice on architecture and sizing, which is part of most cloud solutions engagements.
If you are comparing several estimates and they disagree sharply, an independent review of the assumptions behind each can be more useful than another quote. Project planning and estimate review are part of software consulting.
Key takeaways
- Estimates become more accurate as uncertainty is removed; early figures are ranges.
- Common methods include bottom-up breakdown, analogy, three-point and story points.
- Integrations, business rules, data migration and non-functional needs drive most cost differences.
- Look for stated assumptions, exclusions and contingency in any quote.
- A paid discovery phase is the most reliable way to firm up a large estimate.