Sometimes those assumptions are right. Sometimes the first week reveals that the existing API does not expose the data, the spreadsheet contains rules nobody had written down, or the app needs to keep working with an older system.
That can change the estimate without anyone being dishonest. It can also be a sign that the original quote hid uncertainty instead of explaining it. The difference is whether the assumptions and next decisions are visible.
Look at what the first quote depends on
Ask what the estimate assumes about the existing software, data quality, access, user roles, and review process. Ask what is excluded. A short answer is fine, as long as you can tell what would make the price change.
The riskiest unknown is often not the biggest feature. It may be one integration, one migration, or one business rule that changes how the rest of the system has to work.
Reduce uncertainty in steps
When the whole project cannot be estimated confidently, split the work into decisions. First check the part most likely to change the plan. Then use what you learned to define the next release and estimate that work with fewer assumptions.
This is not a reason to leave the budget open. Agree on a limit for the current step, what it should answer, and when you will review the next estimate. If the work changes, pause and discuss it before the cost changes too.
Questions worth asking
ā¢ Which assumptions are doing the most work in this quote?
ā¢ What is not included?
ā¢ What will we know at the end of the first stage?
ā¢ What would cause you to stop and re-estimate?
ā¢ Can each stage leave behind something useful, even if we pause?
When an estimate changes, compare the new information with the original assumptions. That gives you a better answer than treating every increase as either a scam or an unavoidable surprise.