«How much will it cost?» is the first question of every software project and the hardest one to answer well. A round number at the first meeting is reassuring, but it is almost always a bet: either it is padded to cover what nobody knows yet, or it falls short and the difference shows up later as cuts, delays or arguments. This guide explains how a software project is really estimated, which risks to look at and why a fixed-price quote tends to fail exactly when it matters most.
Why software is so hard to estimate
Building software is not like building a house from finished plans. At the start, much of the work hasn't been decided yet: how a special price is calculated, what happens to an order cancelled halfway, what data the invoicing system you need to connect to returns. Each of those answers changes the work.
Software engineering has a name for this: the cone of uncertainty, described by Barry Boehm and popularized by Steve McConnell. At the beginning of a project, an estimate can be off by up to four times in either direction; the range narrows as decisions are made and the system gets built. It isn't the estimator's lack of experience: the information simply doesn't exist yet.
What gets estimated (and what is usually left out)
Screens are the visible part, but rarely the most expensive one. A serious estimate looks at all of this:
- Features: what each type of user needs to be able to do.
- Business rules: calculations, exceptions, approvals. They usually take the most hours.
- Integrations: invoicing, banks, e-commerce, the system you already have. They depend on third parties and are the number one risk.
- Data: what has to be migrated from spreadsheets or old systems, and what shape it is in.
- What you don't see: testing, security, permissions, servers, go-live, training and documentation.
A quote that only lists screens is leaving out at least half the work.
How to estimate: five steps
1. A short discovery, before the number
Before estimating you need to understand the process: who uses the system, what they do today, with which spreadsheets, what connects to what and what is essential from day one. A few meetings with the people who do the work save weeks of wrong assumptions.
2. Break the project into small pieces
«An order system» can't be estimated; «customer sign-up», «order entry» or «price calculation» can. The smaller the piece, the smaller the error. Pieces that can't be broken down because they aren't understood yet are a signal: that is where the risk is.
3. Estimate with ranges, not a single number
Each piece gets three values: the minimum if everything goes well, the most likely and the maximum if the problems you already suspect show up. A classic way to combine them is PERT three-point estimation: (minimum + 4 × most likely + maximum) / 6. The formula matters less than what the range shows: a piece estimated at 32 to 96 hours needs more attention than one at 16 to 32.
4. Write down assumptions and risks
Every estimate rests on assumptions: «up to three price lists», «the invoicing system has a documented API», «the initial data comes in Excel». Writing them down turns a future argument into a simple conversation: if an assumption changes, the estimate for that piece changes, and both sides know it from the start.
5. Start with a small stage and estimate again
The best way to narrow the cone of uncertainty is to build. A focused first stage, with the essentials, puts the system in the hands of real users and produces concrete data: how long things really took, what came up that nobody had foreseen. With that, the estimate for the rest is far more accurate.
In the case of the work orders for HVAC technicians, the app started with a single equipment family and six technicians; the rest of the equipment and people came in by stages. In the case of the traffic spreadsheet turned into a system, the project was organized as six months of work with partial deliveries, not one final delivery.
Why fixed-price quotes fail
A fixed price looks like the safest option for the buyer: you know what you'll pay and the risk sits with the vendor. In practice, something else happens:
- You pay for uncertainty up front. Whoever quotes a fixed price has to cover the worst case, so the number includes a buffer you pay even if nothing goes wrong.
- Scope is frozen when the least is known. What gets signed at the start is the version of the system with the least information of the whole project.
- Every change becomes a negotiation. Any improvement that comes up while using the system becomes «out of scope», and the project fills up with arguments instead of progress.
- If the buffer runs out, quality gets cut. Testing, documentation and clean code are the first things sacrificed, and that is paid for later in maintenance.
A fixed price does work when the scope is small, well known and hard to change: a single integration, a well-defined module, a data migration with a clear source and target.
Alternatives that work
- Price by stage. The price of the first stage, the best understood one, is fixed, and each following stage is estimated with what was learned.
- Contracted hours with a visible dashboard. A block of hours is agreed per stage and the client can see at any time how many were used and on what.
- Scope changes estimated before they are done. Each new request is logged, its impact on hours and dates is estimated, and it is approved or rejected before work starts. Nothing gets added silently.
With this approach, the budget stops being a one-time bet and becomes a management tool: you know how much was spent, how much is left and which decisions moved the number.
How to read a software quote
Before comparing numbers between vendors, check that each quote includes:
- A breakdown by feature, not a single total.
- The assumptions in writing, and what is not included.
- Testing, go-live and training as items of their own.
- How scope changes are handled.
- What happens after delivery: warranty, support and maintenance.
A quote much cheaper than the rest is rarely a bargain: it is almost always leaving something out. If you are still deciding whether to build or buy an existing product, see custom software vs SaaS.
What to bring to the first meeting
- How the process works today, with the spreadsheets or systems in use.
- Who will use the system and how many people they are.
- Which other systems it has to connect to.
- What is essential for day one and what can wait.
- If there is a deadline, the reason (a season, a legal due date, a contract).
- A reference budget, even a range: it helps propose a first stage that fits.
Common mistakes
- Asking for a number before explaining the process. The number you get is an average of assumptions.
- Choosing on price alone. You end up comparing quotes that don't cover the same thing.
- Wanting everything in the first version. It stretches the project and delays the moment the system starts to be useful.
- Not writing down the assumptions. Later nobody remembers what was included.
- Treating the estimate as a promise. It is the best prediction with what is known today; it has to be updated as more is known.
How Intway can help
We work in stages: a short discovery, an estimate by feature with ranges and written assumptions, and a focused first stage that gets the system running quickly. On hourly projects, you see the hours used and every scope change is estimated and approved before it is done. See how we approach custom software for small and medium businesses, a custom ERP or development team augmentation.