Ask Your Dev Team how they build estimates

A useful software estimate explains what the team knows, what they’re assuming, and what could change the number. A price or deadline without that context is closer to a guess.

Treat it as a forecast for making a decision. Whether it later becomes a commercial commitment depends on your agreement, the scope, and how changes will be handled.

Start with the size of the question

“How much will the app cost?” is usually too broad to answer responsibly. “How much will it cost to let an existing customer reset their password?” is narrower, but even that depends on the current authentication system, design requirements, security rules, and how the change will be tested.

A strong developer first reduces uncertainty. They may review the existing code, sketch a workflow, ask which edge cases matter, or propose a short discovery phase. That work isn’t avoidance. It’s how they replace assumptions with evidence.

The amount of investigation should match the decision. You don’t need a week of analysis to compare two small backlog items. You might need it before committing a large budget to a new product.

Read the estimate in layers

Suppose a team estimates a reporting feature at three to five weeks. First ask what the range measures. Is that elapsed time on the calendar, one person’s effort, or the work of a team? Then look for four layers underneath it:

1. Scope: Which user actions, screens, integrations, and deliverables are included?
2. Assumptions: What does the estimate treat as already decided or available?
3. Uncertainty: Which parts haven’t been validated yet, and how could they affect the range?
4. Exclusions: What might sound related but isn’t included, such as data cleanup, content entry, or support for older systems?

This is where an estimate becomes useful. You can decide whether to reduce scope, investigate a risky dependency, or hold more budget in reserve.

Precision should follow evidence

When important decisions or dependencies remain unresolved, a range is usually more honest than a single number. As the team gathers evidence, that range should narrow. A small, familiar change may reasonably receive a tighter estimate from the start.

False precision is a warning sign. An estimate of 327 hours for an undefined product doesn’t become credible because it has three digits. On the other hand, a developer who refuses to estimate anything isn’t giving you enough help to make a business decision.

The healthy middle is an explicit confidence level: “Based on the workflow we’ve reviewed, this is likely four to six weeks. The payment integration is the largest unknown, so we’d validate that first.”

Ask for the whole delivery effort

An estimate should account for more than writing code. Design, project coordination, testing, deployment, documentation, and review all take time. If your team expects you to provide content, approvals, access, or subject-matter expertise, those dependencies belong in the plan too.

Compare the estimate with the scope and change controls in your agreement. Issue 25 on change orders explains what should happen when the work changes after approval.

Questions worth asking

• “What did you have to assume to produce this estimate?” A thoughtful answer names the assumptions instead of hiding them.
• “What’s included, and what isn’t?” Listen for testing, launch work, and your own responsibilities.
• “Which unknown could move the estimate most?” Strong teams can point to the uncertainty and suggest how to reduce it.
• “What would you change if the budget were 20% lower?” This reveals whether the team understands priorities or simply totaled a feature list.
• “When will you revise this estimate?” An estimate should improve as the team learns.

At Cuttlesoft, we use estimates to support decisions, not win guessing contests. The most credible number is the one whose assumptions you can inspect.

Go build something and expect better from your developer.