"How much will it cost and how long will it take?" Every business owner asks this before commissioning software, and every honest developer answers with some version of "it depends". Behind that answer is a process — sometimes rigorous, sometimes guesswork — that turns a description of your needs into a number. Understanding how estimates are made helps you give better information, compare proposals fairly, spot unrealistic numbers and plan your budget with eyes open. This guide looks inside the estimation process without discussing specific prices.
Why software is hard to estimate
Software estimates are uncertain for three main reasons:
- Unknown requirements. At the start, many details are undecided: exact rules, exceptions, reports, permissions, integrations. Each decision affects effort.
- Unknown complexity. Some features that sound simple — "send an automatic reminder" — involve hidden work: schedules, templates, opt-outs, delivery failures, time zones, logs.
- Unknown unknowns. Things nobody thought to ask about: an old system's undocumented data format, a third-party API's limits, a regulatory requirement discovered mid-project.
Experienced teams have seen enough projects to anticipate many of these, but uncertainty can never be eliminated at the idea stage — only reduced through discovery and design.
The cone of uncertainty
Estimators talk about a "cone of uncertainty": at the very beginning of a project, estimates can easily be off by a factor of two in either direction. After discovery, when scope and workflows are agreed, the range narrows significantly. After design and the first few development cycles, estimates for the remaining work become reasonably reliable. This is why a credible partner gives a broad range at first contact and a firmer plan after discovery — and why a precise number after one meeting should make you cautious rather than reassured.
How a typical estimate is built
1. Break the work down
The team splits the system into modules (orders, inventory, technician app, reports) and then into features or user stories ("a coordinator can assign a job to a technician by area and skill"). The smaller the pieces, the easier they are to estimate.
2. Estimate each piece
Each piece is estimated, often by more than one developer, based on experience with similar work. Many teams estimate in relative sizes first (this feature is about twice as complex as that one) and convert to time using their known delivery pace. Good teams estimate as a range — optimistic, likely and pessimistic — rather than a single figure.
3. Add the work that is not features
Building features is only part of the effort. A complete estimate also includes:
- Discovery, analysis and design.
- Project management and communication.
- Architecture and setup: environments, deployment pipelines, security foundations.
- Integrations with other systems.
- Data migration.
- Testing — automated tests, functional testing, support during user acceptance testing.
- Deployment, launch support and training materials.
- Documentation and handover.
Estimates that leave these out look attractive but are incomplete.
4. State assumptions
Every estimate rests on assumptions: "the client will provide product data in a clean spreadsheet", "the accounting system's API supports creating invoices", "reports are limited to the twelve listed", "the mobile app supports Android and iOS phones from the last few years". Assumptions are where scope disagreements later come from, so they should be written down explicitly.
5. Add contingency for risk
Known risks — an integration nobody has tested, unclear rules in a complex area — are given contingency. Contingency is not padding; it is an honest allowance for things likely to go wrong somewhere. How it is handled depends on the contract model.
What makes estimates grow during a project
- Scope growth — new features and changes added without removing others.
- Discovered complexity — rules or exceptions that emerge with real data.
- Integration surprises — third-party systems that behave differently from their documentation.
- Data quality — migration that requires much more cleaning than expected.
- Slow decisions — teams waiting for answers lose momentum and time.
- Changing people — key people on either side leaving or being replaced.
Most of these can be anticipated and managed; some are on the client side.
How to read an estimate
When you receive an estimate or proposal, look beyond the total:
- Is the scope described in business language? Can you recognise your processes in it, or is it a list of technical components?
- Is there a breakdown? By module or feature, so you can see what drives effort.
- Are non-feature activities included? Testing, project management, deployment, migration, documentation.
- Are assumptions explicit? And do you agree with them?
- Are exclusions listed? What is clearly not included?
- Is uncertainty acknowledged? A range, or a statement of what will be refined after discovery?
- Are third-party costs separated? Hosting, licences, API and messaging fees, app store accounts.
- Is the timeline consistent with the effort? A large effort squeezed into a short timeline implies a large team — or optimism.
Comparing estimates from different companies
Large differences between proposals are normal. Before comparing totals, normalise them:
| Check | Why it matters |
|---|---|
| Same scope understanding? | One company may have assumed a simpler version of a key feature. |
| Same platforms? | Web only versus web plus Android and iOS apps is a big difference. |
| Testing and QA included? | Some proposals assume the client will do all testing. |
| Integrations and migration included? | Often the riskiest items, sometimes left out. |
| Support and warranty? | Post-launch fixes may be included, limited or charged separately. |
| Team experience? | An experienced team may estimate fewer hours for the same work. |
| Contract model? | Fixed price includes risk premium; time and materials does not. |
Ask each company to walk you through their estimate. How they explain it tells you a lot about how they will run the project.
Red flags
- A precise fixed figure after a single short conversation.
- No questions about your processes, data or integrations.
- No assumptions or exclusions listed.
- Testing, deployment or project management missing.
- An estimate far below others with no clear explanation.
- Pressure to sign quickly to "lock in" the price.
Using estimates to make better decisions
An estimate broken down by feature is a decision tool. If the total is above your budget, you can see which features drive effort and decide what to defer to a later release. Often, a small number of complex features — a highly flexible report builder, a complex pricing engine, an offline sync for every screen — account for a large share of the effort. Simplifying or postponing them can make the first release affordable without losing its core value.
Many businesses use a two-step approach: a short, fixed discovery that produces a refined estimate for the first release, followed by a decision to proceed. This turns a vague early range into a number you can plan around.
How you can make estimates more accurate
- Share real documents: forms, spreadsheets, reports, invoices, WhatsApp messages that show how work happens.
- Give access to the people who do the work, not only managers.
- Describe exceptions, not just the normal flow.
- Be clear about must-haves versus nice-to-haves.
- Identify integrations early and obtain technical details from other vendors.
- Be honest about data quality.
- Name the decision-maker and commit to quick answers.
Example
A company requested proposals for a dealer ordering portal with a sales app. Three proposals arrived with totals that differed widely. On closer reading, the lowest assumed web only, excluded integration with the company's inventory system and limited testing to developer checks. The highest included Android and iOS apps, full integration, migration of dealer data and a three-month support period. The middle proposal proposed a paid discovery to clarify integration and app requirements before committing. The company chose the discovery; it revealed that the sales app could be a progressive web app for the first release and that inventory integration was straightforward. The refined estimate for release one was well within budget, and the native apps were planned for release two.
Summary
Software estimates are built by breaking work down, estimating pieces as ranges, adding non-feature activities, stating assumptions and allowing for risk. Early estimates are inherently uncertain and should narrow after discovery. Read estimates for scope, breakdown, inclusions, assumptions and exclusions — not just the total — and compare proposals only after normalising them. Use the breakdown to make trade-offs, and help your partner estimate well by sharing real information and deciding quickly.
Designing to a budget instead of estimating a wish list
Many businesses already know roughly what they can invest in the first release. In that case, it is often more useful to reverse the question: instead of "what will all of this cost?", ask "what is the most valuable system we can build within this budget?". The development team estimates the prioritised feature list, draws a line where the budget runs out, and works with you to move features above or below the line. Complex features can often be simplified to fit — a fixed set of reports instead of a report builder, or offline support only on the screens technicians use on site. Designing to a budget keeps the conversation about value, and it avoids the disappointment of a full wish-list estimate that has to be cut in half.
Estimating the cost of running the software
The development estimate covers building the first release. A complete budget also includes running and improving the software afterwards: hosting and third-party services, support and maintenance, updates for new phone and browser versions, security updates, and enhancements as the business changes. Ask your partner to describe these ongoing activities and how they are usually charged, so the software's total cost over several years is visible before you decide. Systems that are actively used almost always need continued investment; budgeting for it from the start avoids the slow decline of software nobody is paid to maintain.
Contingency versus padding
Business owners sometimes suspect that contingency is simply padding. The difference is transparency. Padding is hidden extra time spread across every item. Contingency is a visible allowance linked to named risks — "the inventory system's API has not been tested; we have allowed extra effort for integration issues" — and reviewed as those risks are resolved. Ask your partner which risks the contingency covers and what happens to it if they do not materialise. A clear answer is a good sign of an honest estimate.
Frequently asked questions
Why do two companies give very different estimates for the same project?
Usually because they have understood the scope differently, made different assumptions or included different activities such as testing, project management, deployment and support. Compare the assumptions and inclusions, not just the totals.
Why do estimates come as ranges?
Because early in a project, important details are still unknown. A range honestly reflects that uncertainty. The range should narrow as discovery and design answer open questions.
Is the lowest estimate the best choice?
Not necessarily. A low estimate may leave out testing, ignore integrations, assume unrealistic speed or plan to recover the difference through change requests. Understand why it is low before choosing it.
How can we make estimates more accurate?
Provide real examples of your documents, data and workflows; invest in a short discovery; answer questions quickly; and agree a prioritised scope so that the first release is clearly defined.
Should we ask for an estimate per feature?
A breakdown by major feature or module is very useful: it shows what drives effort and lets you make informed trade-offs about what to include in the first release.
