Nobody can estimate a six-month software build accurately. Not us, not the vendor quoting half our price. The interesting question is what you do about that, because the usual answer — pad the number and hope — serves nobody.
Estimates fail structurally
A software estimate is a forecast about work that has never been done before, made at the point of least information. The parts that blow up are rarely the features on the list. They are the integration whose documentation was wrong, the edge case nobody mentioned, the approval that took five weeks.
- Requirements are discovered during building, not before it
- Third-party systems behave differently in production than in sandboxes
- The hard part is usually the part nobody thought to describe
- Organisational delays are invisible in a technical estimate
Fixed price hides the risk, it does not remove it
A single fixed price for a long build prices in the vendor's uncertainty. You pay for the risk whether or not it materialises, and when it does, the pressure lands on scope quality rather than the budget.
A number quoted with confidence months in advance is a sales position, not an engineering one.
What we do instead
We price per two-week cycle after a short discovery. You know the cost of the next increment before it starts, you see working software at the end of each one, and you can stop at any cycle boundary. Our incentive is to keep being worth renewing.
This is not a trick to bill more. It means uncertainty is handled in the open, in short intervals, rather than buried in one number and argued about later.