Skip to content

Why software estimates break, and how to structure a project so they matter less

Estimates fail predictably. Structuring delivery around observable increments removes most of the commercial risk that bad estimates create.
6 min readRashid LLC

Every software estimate is a forecast made with incomplete information, and forecasts made with incomplete information are wrong. That is not a failure of professionalism — it is a property of the activity. What separates a well-run project from a badly run one is how much damage a wrong estimate is allowed to do.

The three usual causes

  • Unknown integrations. Third-party systems behave differently from their documentation, and you find out only once you are connected to a real account with real data.
  • Undiscovered requirements. The exception nobody mentioned in discovery — the customer type that is billed differently, the report finance cannot operate without — surfaces mid-build.
  • Existing systems. Work touching an established codebase carries the cost of understanding it, and that cost is invisible until the work starts.

Structure beats precision

Rather than trying to estimate more accurately, structure the project so that being wrong is survivable. Two practices do most of the work.

The first is a paid discovery phase that ends in a written architecture and scope. It is a small, fixed commitment that converts the largest unknowns into documented decisions before anyone commits to a delivery date. The output belongs to the client regardless of whether the build proceeds.

The second is delivering in increments a client can see running. A staging environment updated continuously means progress is observable rather than reported. Misunderstandings surface in week two, when they are cheap to fix, instead of at handover.

What a client should insist on

  1. 01Scope in writing, with what is explicitly excluded stated as clearly as what is included.
  2. 02Access to a working environment from early in the build, not a demo at the end.
  3. 03A written change process — how a new requirement affects cost and date, agreed before it is needed.
  4. 04Regular written updates, so a status question never requires a meeting.

None of this makes estimates accurate. It makes them less consequential, which is the achievable goal.

Written by the team at Rashid LLC. We build custom software, AI automation and cloud infrastructure for businesses in the US and internationally.

Talk to us about a project
Get in touch

Have a project in mind?

Let's build something useful. Tell us what you're trying to achieve and we'll come back with an honest view of what it takes.

Within 1–2 business days · Working with clients in the United States and internationally