Software Estimation: Give Founders Ranges They Can Use

TL;DR — Software estimation is a stated range based on known work, unknowns, and assumptions. A useful estimate changes a decision; a single date with hidden uncertainty usually creates a promise nobody can manage.

Software estimation is difficult because a product request is not a stack of known tasks. It contains discovery, design choices, dependencies, edge cases, review, deployment, and learning. Founders do not need an engineer to predict the future perfectly. They need a transparent basis for choosing scope, sequencing risk, and deciding when more discovery is cheaper than a bigger commitment.

Start by refusing false precision. “It will take six weeks” sounds decisive but says nothing about what has been assumed. “Four to eight weeks for the named onboarding flow, assuming existing identity, no data migration, and one external integration” can be challenged, reduced, or approved.

Estimate a slice before a product

The most valuable input is a small product requirements document. It should name the user outcome, constraints, exclusions, and acceptance criteria. Without that, an estimate measures how much uncertainty is hidden in the conversation rather than the work itself.

Break the work into testable slices: discovery, interface and data design, core path, integrations, safety and permissions, migration or import, verification, and release readiness. This is not a schedule yet. It is a way to expose unknowns. An integration whose documentation has not been tested is not “two days”; it is a discovery item with a range.

The U.S. Government Accountability Office’s cost estimating guide emphasizes a documented technical baseline, assumptions, risk and uncertainty analysis, and updates when new information arrives. The domain is broader than a startup product, but the discipline transfers well: explain the basis and revise rather than defending an old number.

Use a range with decision points

Give a low, likely, and high case. The low case assumes the stated path works. The likely case includes ordinary iteration. The high case includes named risks, such as an undocumented legacy export or a vendor approval. Do not average them into a comforting number; show what would move the estimate.

For a hypothetical example, a founder wants a customer self-service billing page. The team may estimate one week for the core UI, two to four days for entitlement rules, and an unknown discovery slice for reconciling historic invoices. The right next action is a short investigation that either converts the unknown into scoped work or changes the product decision. The numbers are illustrative only; the method is the point.

Tie each range to a decision. If the high case exceeds the launch window, reduce the first release: perhaps show invoice history before enabling changes, or support one plan type before every legacy exception. Estimation is useful when it protects an outcome by reducing scope deliberately.

Track estimate accuracy without punishment

After a release, compare the range with the actual effort and record why it differed. Was the requirement unclear? Did a dependency change? Was the technical approach wrong? Did review uncover a safety issue? The point is to improve future assumptions, not to score people for encountering reality.

Do not use estimates as a proxy for individual performance. That rewards hiding risk and discourages early disclosure. Instead, reward the behavior a founder needs: a person who identifies uncertainty early, proposes a bounded experiment, and updates the plan before a commitment becomes expensive.

Estimate costs and choices separately

Time is not the only decision variable. A solution can be quick to build yet create a permanent operating burden, or slow to build but remove a material vendor dependency. Pair the delivery range with a simple ownership note: who runs it, what it costs to maintain, what can fail, and how it can be changed. That is the bridge to a real build versus buy decision.

If a choice depends on payback rather than engineering feasibility, use a break-even calculator with explicitly hypothetical inputs. It will not create certainty, but it makes the assumptions inspectable.

Good software estimation gives a founder a steering wheel. It reveals what the team knows, what it does not, and which small action will reduce the uncertainty enough to choose the next release.

Sources

• U.S. GAO: Cost Estimating and Assessment Guide
• NIST: Guide to Software Acceptance