How to estimate a software project without lying to yourself or the client

Software estimates are not promises about the future. They are structured explanations of what we know, what we do not know, and how much uncertainty the plan can absorb.

“How long will it take?” is the right question asked too early

Clients need dates. Teams need budgets. Nobody can run a business on ‘we will know when we know.’ The problem is not estimating; it is pretending uncertainty disappears because a number has been typed into a proposal.

A responsible estimate should become more precise as the team learns. Early estimates are ranges. After discovery, architecture and dependency checks, the range should narrow.

Estimate journeys, not screens

Counting screens is tempting because screens are visible. But the hard work usually lives between them: sign-in states, permissions, payment retries, data migrations, admin workflows, notifications, audit trails, and all the ways a third-party service can fail.

Instead, estimate complete user journeys and the systems that support them. ‘Book an appointment’ includes far more than the appointment screen.

Diagram: five simple screens above a red dividing line, and below it a dense web of permissions, retries, notifications and security checks wired around a database — The expensive work often lives between screens.

Separate known work from risk

We like estimates that make risk visible. A standard CRUD module — the ordinary create, read, update and delete screens — is predictable. Integrating with a legacy hospital system that has no test environment is not. Treating both as equal-sized tickets hides the information decision-makers need most.

A useful estimate has at least four buckets:

The four buckets

Known product work
Integrations and dependencies
Quality/release work
Explicit uncertainty

Diagram: four columns of stacked bricks for known product work, dependencies, quality and release, with the fourth outlined in a dashed red border for explicit uncertainty — Make uncertainty visible before it becomes delay.

Do not hide QA and launch inside development

A feature is not done because a developer can run it locally. It still needs testing across devices, error states, analytics, real content, deployment configuration, a migration plan, app-store work, and whatever the support team will need on day one.

If QA is ‘included’ but not visible in the estimate, it usually means QA is the first thing squeezed when the date becomes uncomfortable.

Use ranges where ranges are honest

If a discovery-phase estimate is 10–14 weeks, that is more useful than writing 12 weeks in bold and quietly hoping. Ranges communicate uncertainty without abandoning accountability.

Then explain what moves the project toward ten or fourteen: feedback speed, integration readiness, content availability, scope decisions and technical unknowns.

False precision feels professional right up until reality arrives.

Re-estimate when reality changes

An estimate is not a tattoo. If the client adds a workflow, an external API changes, or user testing invalidates an assumption, update the plan and explain the consequence.

The unhealthy version of ‘agile’ is keeping the original date, adding the new work, and discovering physics during the final week.

Diagram: a cone of uncertainty narrowing from discovery through build to release — Good estimates get more precise as the team learns.

The best estimate is a shared model

Good estimation creates a shared mental model of the project. The client understands what is expensive and why. Engineers understand which outcomes matter. Project managers know where uncertainty lives.

That is more valuable than false precision. A trustworthy estimate is not the one that never changes. It is the one that changes for reasons everyone can understand.

How to estimate a software project without lying to yourself or the client.