How to estimate a software project: a buyer’s guide to reliable numbers

To estimate a software project, a development team breaks the requirement down into features, sizes each one against similar past work, adds the items buyers tend to forget (integrations, data migration, testing, deployment) and applies a buffer proportional to what is still unclear. The result is only as reliable as the brief behind it. When two quotes differ widely, they are almost always pricing two different projects. The best way to get an accurate number is to remove ambiguity before asking for a price, not to collect more quotes.

This guide is written for the person signing off the budget: a founder, an operations director, a business owner. It explains how estimates are built on the vendor side, why they go wrong, and what you can do to make yours more dependable.

Estimate, quote, commitment

Three different things tend to get called "the price":

• an estimate is an assessment of effort and cost, with a margin of error. It commits nobody;
• a quote (or proposal) is a commercial offer for a described scope, with terms attached;
• a commitment is what the contract actually guarantees: a price for a scope under a fixed-price contract, or a rate per day or hour under time and materials.

A number mentioned in the first call is an estimate, however confidently it is delivered. Until it is tied to a written scope, it is not a commitment. Our comparison of fixed price and time and materials explains who carries the risk under each model.

How vendors actually estimate

Behind most quotes sits a mix of the same few techniques.

Agile teams often size work in relative units such as story points before converting to time. The unit matters less than the habit behind it: estimating in small pieces, comparing against real past delivery, and re-estimating as you learn.

The breakdown that drives the number

A solid bottom-up estimate goes beyond the visible features. It covers:

• features: data entry, search, approvals, calculations, exports, notifications;
• roles and permissions: who sees what and who approves what;
• integrations: ERP, accounting, CRM, payments, e-signature, single sign-on;
• data migration: from spreadsheets, a legacy system, an Access database;
• non-functional requirements: security, backups, performance, audit logs, privacy compliance;
• delivery work: design, QA, bug fixing, deployment, documentation, training.

The last two groups are the ones most often missing from a quick estimate, and the ones most likely to come back later as change requests.

The risk buffer

An honest estimate does not just add up tasks. It includes a buffer for what is still unknown, larger where the brief is vague: an integration with an API nobody has looked at yet, a pricing rule described in one sentence, a data migration that has never been tested. That buffer is not padding. A vendor who leaves it out will usually recover it later, through change requests or through quality.

Why early estimates are wrong

Estimation uncertainty shrinks as a project gets defined. Software engineers call this the "cone of uncertainty", popularised by Steve McConnell in Software Estimation: Demystifying the Black Art (Microsoft Press, 2006), building on Barry Boehm’s work from 1981. According to Construx, McConnell’s firm (accessed 6 November 2026), an estimate made at the initial concept stage can end up as much as four times too high or four times too low, and the range narrows as product definition and requirements are settled.

Two caveats. The bounds reflect the authors’ experience rather than a measured dataset, so treat them as an order of magnitude. And the cone does not narrow on its own with the passing of time. It narrows because decisions get made: which screens, which rules, which integrations, what is out of scope. A project that keeps moving without those decisions stays at the wide end of the cone, months in.

The practical takeaway: a precise number in the first meeting is not a sign of competence. Often it is the opposite.

What really drives the cost

The same one-line description ("a field service app", "a customer portal") can hide very different budgets. The usual swing factors:

1. Business rules and their exceptions. A two-step approval flow is quick to build. The same flow with delegation, thresholds by amount and customer-specific exceptions takes several times longer.
2. Integrations. Each connection depends on the quality of the other system’s API, its documentation and access to a test environment.
3. Data migration. Exporting is rarely the hard part; cleaning duplicates and repurposed fields is.
4. Roles and permissions. Three roles and twelve roles are not the same product.
5. Availability and security requirements. An internal tool for ten staff and a platform open to your customers need different levels of rigour.
6. Mobile and offline use. Field data entry without a connection adds sync logic and edge cases.

For ballpark figures by type of application, see our guide to what a custom business application costs.

Why quotes for the same project diverge

The cheapest quote is not necessarily the cheapest project, and the most expensive is not necessarily the safest. Our guide on how to compare software development quotes shows how to put several proposals into one grid.

What you can do to get a reliable estimate

The quality of an estimate depends first on what you hand over. In rough order of impact:

Describe the problem before the solution

Explain how work happens today: who does what, with which tools, how often, where time is lost. Vendors estimate a real process far better than a feature wish list drafted in a meeting.

List the rules and their exceptions

"The manager approves orders" is not enough. Above what amount? What happens when the manager is away? Can an approved order be edited? Every exception known up front is a change request avoided. Our software development RFP template gives a structure for this.

Name the systems to connect and share sample data

The name and version of your ERP, whether it has an API, an anonymised export of the data to migrate: these turn a line priced on gut feel into a task that can actually be sized.

Separate must-haves from nice-to-haves

Label each feature as needed on day one, needed later, or comfort. Ask for an estimate per block. You can then trade scope without a full re-quote, and start with a shorter first release. Our article on what to build first in an MVP helps with that cut.

Show instead of describe

A screen is worth a page of text. A rough wireframe, or better a clickable prototype, surfaces misunderstandings before pricing: a missing field, a useless screen, a flow users will not follow. It is the quickest way down the cone of uncertainty. See prototype vs MVP vs POC for what each one proves.

Share your budget

Many buyers hide it, fearing the vendor will simply match it. That rarely pays off: without a budget, every vendor imagines a different solution and the quotes cannot be compared. With one, a good vendor tells you what fits and what does not.

How to read the estimate you receive

A serious estimate includes at least:

• a range, or a firm price tied to a precise scope;
• written assumptions;
• explicit exclusions;
• a breakdown by feature block, so you can make trade-offs;
• the items beyond coding: design, QA, deployment, hosting, support;
• what would move the price, and in which direction.

Always ask: "what would push this from the low end to the high end of the range?" The answer tells you where the risk sits, and often which decisions to make now to reduce it.

Common buyer mistakes

• Demanding a fixed price on a vague brief. The vendor protects itself with a large buffer or a narrow scope, and you pay for one or the other.
• Negotiating the number down without touching the scope. The work does not shrink; only the safety margin disappears.
• Forgetting the years after launch. Hosting, maintenance and new features cost money every year.
• Confusing effort with calendar time. Twenty days of effort do not ship in twenty calendar days once reviews, QA and your own availability are counted. Our article on how long it takes to build an app covers the gap.
• Never re-estimating. The first-meeting number is obsolete once discovery is done.

When a precise estimate is the wrong goal

For some projects, chasing an exact number costs more than the error it avoids: a simple tool whose scope fits on one page, or a new product whose right features nobody, you included, knows yet. Two healthier approaches:

• work to a fixed budget: set the money and the date, then build the best version that fits, prioritising ruthlessly;
• move in short steps: ship a useful first release, learn from real users, then estimate the next step from what you learned.

You do not have to pay everything up front either. Development can also be funded through a monthly subscription, which shifts the question from "how much will it cost to build?" to "what does it deliver each month?".

Where to start

1. Write one page on the problem, the users, the current tools and your budget.
2. List the rules and exceptions you already know.
3. Prepare sample data and the names of the systems to connect.
4. Make the requirement visible before asking for a firm price.

For that last step, we build a free visual prototype, presented over video within 5 working days. You see the screens and flows before any pricing, and the estimate that follows covers what you approved rather than a written description.