How to Get a Software Development Estimate You Can Budget On

A software development estimate is a forecast of how many hours a piece of software will take to build, and a useful one always comes as a range with written assumptions, not a single number. To get an estimate you can budget on, give the developer a clear brief, ask for the range broken down by part and set your budget at the top of the range, not the bottom. The more you settle before the estimate is made, the narrower the range gets, which is why a short discovery phase is the most reliable way to get a number you can trust.

The short answer: how accurate can an estimate be?

Accuracy depends mostly on how much is known when the estimate is made. These are my rules of thumb for the gap between the low and the high end.

The exact figures are my own, but the pattern is well documented. Barry Boehm brought the model into software, and the research behind it suggests that an estimate made before requirements are gathered can be off by up to a factor of four in either direction, with the uncertainty shrinking as decisions get made. It's known as the cone of uncertainty, and the part people miss is that the cone only narrows when someone does the work of removing the unknowns.

For typical price levels by project type, see my software development cost guide. This post is about getting a reliable number for your own project.

Estimate, quote, fixed price, budget: not the same thing

A lot of frustration with estimates comes from treating these four words as interchangeable.

The most common mistake is taking the low end of an estimate and calling it the budget. That turns a guess into a promise nobody made. A fixed price moves the risk to the developer, and the buffer is what you pay for that. I've laid out the trade-offs in fixed price vs hourly rate.

The second mistake is confusing an estimate with a deadline. One tells you how long something takes, the other when you need it. When they don't match, cut scope. Don't ask the developer to guess lower.

Why software estimates slip

Every software project is at least partly new. If it weren't, you could probably buy it off the shelf. The same causes of misses come up again and again:

• Integrations nobody has tested. Third-party APIs rarely behave exactly as documented, and sandbox access can take weeks to arrange. Payment and tax logic adds its own surprises, for example VAT when you sell to customers in several EU countries.
• Decisions put off. "We'll figure that out later" is one of the most expensive sentences in software, because later usually means rework.
• New ideas mid-build. They're normal and often good, but each one has to replace something or get its own price.
• Work that wasn't estimated. Testing, server setup, meetings, bug fixing and handover get forgotten when only features are estimated.
• Plain optimism. Daniel Kahneman and Amos Tversky described the planning fallacy in 1979: people consistently underestimate how long tasks take, even when they know similar tasks ran late before.

That's why overruns are lopsided. A task can finish a little early, but it can run late by a multiple. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and found an average cost overrun of 27%. The average hides the real risk: one project in six overran its budget by 200% on average, and its schedule by almost 70%.

Their sample was large IT projects, so the numbers don't transfer directly to a €30,000 web app. The lesson does: the damage sits in the tail, and a good estimate has to account for it.

How to read a software estimate

A good estimate shows you where the uncertainty sits, so you can do something about it. Here's a made-up example for a small B2B customer portal, in hours:

At €100 an hour excluding VAT, a round number for the example and not my rate, that's €21,000-35,000. That range is too wide to sign off on, but the estimate tells you exactly why: the two integrations and the open questions about the dashboard account for about 60% of the spread. Settle those three and the range shrinks.

Some developers give three numbers per item: optimistic, most likely and pessimistic. That's more honest than a single figure, because you see both the best and the worst case.

Three things to check in any estimate:

• Is it broken down? You can't question, or cut from, a single figure of 250 hours.
• Are the assumptions written down? "HubSpot's API supports the sync we need" is an assumption. If it's wrong, so is the estimate.
• What's left out? Design, copywriting, data migration, hosting and maintenance are the usual gaps, along with whether prices include VAT. If you're weighing several estimates, my guide to comparing software development quotes shows how to line them up fairly.

How to get an estimate you can budget on

You can't get a precise estimate for a fuzzy idea, but you can get the most precise number your project allows:

1. Describe the problem, not just the features: who will use the software, what they do today and what should get better. That leaves room for the developer to suggest a simpler route than your feature list.
2. Share your budget range. Without one, the estimate covers the most expensive version of your idea. With one, you can shape the solution to fit.
3. Ask for a range broken down by part, like the example above, so you can see what's expensive and what's uncertain.
4. Get assumptions and exclusions in writing. When something changes later, this is the document you'll reach for.
5. Ask for the three biggest risks and what each could cost. A developer who can't answer hasn't thought the project through.
6. Remove the biggest unknown before you commit. That might be a discovery phase, or a small paid test of the riskiest part, such as a few hours proving that an integration works.
7. Budget for the high end, plus a reserve. My rule of thumb is 10-20% on top of the high end for the changes you'll want once you see the software in use. My software project budget template shows how to set it up.
8. Agree how progress gets reported. Ask to see hours spent against the estimate after each phase, and to be told as soon as a part starts slipping. If your developer is in another country, fix a weekly check-in that suits both time zones.

Why discovery narrows the range so much

A discovery phase is a short, paid phase before the build where the solution gets worked out and estimated. I sell fixed-price discovery phases myself, so read this section with that in mind. It's also why the next section covers when precision isn't worth paying for.

Discovery narrows the range for four reasons, and none of them involve the developer guessing better:

• Unknowns become knowns. Integrations get checked against real documentation and sandbox access, and existing data gets reviewed. Those are exactly the items with the widest spread in the example above.
• Decisions get made. Who can see what? What happens when a payment fails? Which features can wait? Every answer removes a source of variance.
• Tasks get small. A one-day task is far easier to estimate than a one-month task. Discovery breaks the work into pieces small enough to judge one by one.
• Scope gets prioritized. With a must-have, should-have and later list, you can trim until the narrow range also fits your budget.

There's a fifth benefit that's easy to miss: the estimate comes from the person who'll build the software and has to live with the number. That's how I work on larger projects: once discovery is done, a fixed price or a tight range for the first phase becomes realistic because the guesswork is gone. For typical prices and what you should walk away with, see what a discovery phase costs.

When a precise estimate isn't worth paying for

Precision costs time, and sometimes it isn't worth it:

• Small jobs. A change or an integration under roughly 100 hours can usually be estimated well enough from a call and a written brief. A discovery phase would eat too much of the budget.
• Products you'll learn your way into. If you're building a first version to find out what customers want, a detailed estimate for everything is wasted effort. Fix the budget per period and keep the scope flexible. That's the core idea behind choosing agile over waterfall.
• Go/no-go decisions. If you only need to know whether the idea is realistic at all, a rough range is enough. The precise number can wait until you've decided.

There are also cases where I'm the wrong person to ask. If you need a binding fixed price for a large, undefined project after one call, I'll say no. Some suppliers will happily give you that number, but they have to build in a large buffer to do it, and you pay for that buffer whether the risk materializes or not.

Next steps: prepare before you ask for an estimate

The better your input, the tighter the range from the very first conversation. Run through this list before you ask me, or anyone else, for an estimate.

You can see how I price discovery and development, and how an estimate turns into a fixed price afterwards, on my pricing page. You'll talk directly to me, the developer who writes the code, and you'll get a reply within one business day.

Frequently asked questions

How long does it take to get a software development estimate?+

A rough range usually takes one call and a written brief, often within a few days. An estimate you can budget on takes more work, and for larger projects that typically means a discovery phase of one to three weeks. The pace is rarely set by the developer. It's set by how quickly questions about scope, data and integrations get answered on your side.

Should I trust a free estimate?+

A free estimate is fine as a reference point, but rarely something to budget on. It's usually put together quickly, without anyone checking integrations or data, so the uncertainty is high even if the number looks precise. Use it to judge whether the project is realistic, then pay for proper scoping once the budget is large enough for a miss to hurt.

What should I do if the project is running over the estimate?+

Pause and find out why before you approve more hours. If the scope has grown, cut something else or move it to a later phase. If a part was simply underestimated, ask for a fresh estimate on the remaining work so you can decide with current information. The most expensive option is carrying on and hoping it fixes itself.

Should estimates be in hours or story points?+

For budgeting, you need hours or money. Story points are a relative measure many agile teams use to compare tasks with each other, for example that one task is twice the size of another. They help a team plan its sprints, but you can't put them in a budget. Any good developer or agency can translate points into hours or a cost range on request.

Can I share one developer's estimate with others to get competing quotes?+

Yes, if you have the rights to the material, which should be stated in your contract. A breakdown with written assumptions makes a good brief to send around, because everyone then prices the same solution. The descriptions are more useful than the numbers. Before paying for discovery, ask if you're free to share the output with other suppliers.