"How long will it take?"
It's the question every client asks. And the honest answer is: we're probably going to be wrong.
Here's why that happens, and how to deal with it.
Why Estimates Are Hard
Software Is Exploration
Building software isn't like building a house. You're not following blueprints — you're discovering solutions as you go.
Requirements that seem simple turn out to be complex. Edge cases emerge. Integration points don't work as documented. The "easy part" becomes the hardest part.
Unknowns Are Unknown
You can estimate what you understand. You can't estimate what you haven't discovered yet.
Projects routinely uncover:
- Data quality issues
- Undocumented business rules
- Integration challenges
- Performance requirements
- Missing requirements
Each discovery affects the timeline.
Optimism Bias
Developers are optimists. They imagine the happy path — everything works, no problems, smooth sailing.
Reality includes debugging, testing, edge cases, waiting for decisions, and all the unglamorous work that takes time.
Scope Changes
Even well-defined projects change. You see the software and realize something needs to be different. That's not failure — that's learning.
But every change affects the estimate.
Why Developers Give Estimates Anyway
Because you need them.
You need to:
- Budget for the project
- Plan around the timeline
- Compare options
- Make go/no-go decisions
So we estimate, knowing we'll probably be wrong, trying to be wrong in predictable ways.
Types of Estimates
Rough Order of Magnitude (ROM)
Accuracy: ±50% or more When: Very early, before detailed requirements Use for: Determining if project is even feasible
"Building something like this typically costs $30K-$80K."
Budgetary Estimate
Accuracy: ±25% When: After initial discussions, before detailed analysis Use for: Budget planning, proposal decisions
"Based on what we know, expect $45K-$65K."
Detailed Estimate
Accuracy: ±10-15% When: After thorough discovery and requirements analysis Use for: Contracts, project planning
"This project is $52,000, with assumptions documented."
What "Fixed Price" Actually Means
Fixed price doesn't mean "unlimited scope for a set cost."
It means: "For this specific scope, documented in detail, the price is fixed."
Change the scope, change the price. That's not a loophole — that's reality.
How to Get Better Estimates
Invest in Discovery
The more you understand upfront, the better you can estimate.
Paid discovery phases (1-2 weeks) dramatically improve estimate accuracy. Worth the investment.
Document Assumptions
Every estimate makes assumptions. Make them explicit:
- "Assumes existing user database can be accessed via API"
- "Assumes no more than 5 custom reports"
- "Assumes standard authentication, not SSO"
When assumptions prove wrong, expectations adjust.
Break It Down
A single estimate for "the whole project" hides uncertainty.
Breaking into smaller pieces reveals where confidence is high vs. low.
Plan for Change
Budget time and money for the unknown. 15-25% contingency is reasonable.
Use Ranges
"6-8 weeks" is more honest than "7 weeks."
If someone gives you a single number with false precision, be skeptical.
What to Watch For
Red Flags
🚩 Precise estimates before understanding the problem 🚩 "No problem, we can do that" to everything 🚩 Unwilling to explain assumptions 🚩 Fixed price with vague scope 🚩 Significantly lower than everyone else (what are they missing?)
Green Flags
✅ Explains estimation approach ✅ Documents assumptions ✅ Uses ranges ✅ Asks clarifying questions before estimating ✅ Honest about uncertainty
Dealing With Overruns
When the estimate proves wrong:
If It's Scope Change
Fair to renegotiate. You asked for something different than originally specified.
If It's Estimation Error
Reasonable vendors absorb some of this. It's the cost of being wrong.
But chronic underestimation by 50%+ is a problem with the vendor, not just estimation.
If It's Discovery
Requirements turned out differently than assumed. Shared responsibility to adapt.
Good Communication
Problems are manageable if surfaced early. "We're tracking ahead of estimate, here's why" beats surprise overruns.
The Honest Truth
Perfect estimates don't exist in software.
Good estimates come from:
- Experienced estimators
- Thorough understanding of requirements
- Honest communication about uncertainty
- Documented assumptions
- Appropriate contingency
The goal isn't perfection — it's predictable, manageable uncertainty.
Questions to Ask
- "What's your confidence level in this estimate?"
- "What assumptions does this estimate make?"
- "What's the biggest risk to this estimate?"
- "How will you communicate if we're trending over?"
- "What's included in contingency?"
We estimate honestly and communicate proactively. Let's talk about your project