3 Months or 5 Days, Who Should You Believe?

3 Months or 5 Days, Who Should You Believe?

When I was working as a startup CTO, I once designed a feature and asked a senior developer how long it would take.
The answer was three months.

As a former developer with years of project experience, it felt unrealistic.
So I asked a newly joined developer the same question.
His answer was five days.

Three months versus five days.
For managers or executives without hands-on project experience, this is nothing short of a disaster.

Who is wrong?
Possibly no one.

Experienced developers often include hidden costs, requirement changes, QA cycles, communication overhead, deployment risks.
Newer developers usually estimate pure implementation time under ideal assumptions.

The real problem isn’t people.
It’s the absence of shared, comparable criteria.

Without data, past execution records, variance, risk factors, estimation becomes a matter of trust and intuition.
And intuition is a fragile foundation for business decisions.

Development schedules shouldn’t rely on who speaks louder or sounds more confident.
They should be explainable, comparable, and grounded in evidence.