An unfinished project is not estimable from a feature list alone. The remaining work depends on what can be built, what the current system actually does, and which assumptions still need evidence.
Define the estimate boundary
Separate discovery, recovery and feature delivery. A quote for a new reporting screen should not silently include restoring a broken deployment pipeline or reconciling undocumented database changes.
Gather the minimum evidence
Ask for repository access, runtime details, deployment steps, representative data, critical workflows, recent failures and third-party dependencies. Missing access is an estimate risk, not a reason to invent certainty.
Score risk by workflow, not by code size
Prioritise workflows that move money, change permissions, write inventory, send customer messages or expose regulated data. A small change in one of these paths may require more proof than a large isolated interface change.
Use a range with assumptions
State what the range includes, what access is assumed, which workflows are covered and what evidence could expand the scope. This makes the estimate reviewable instead of defensive.
Create a paid discovery milestone
For unknown systems, the first milestone should produce a reproducible environment, system map, risk register and delivery options. It converts hidden uncertainty into explicit decisions.
Common failure mode
Avoid a fixed total before the system can be built and the critical workflow is traced. The hidden work does not disappear; it becomes an emergency, a dispute or a compromised release.
Related services
For a bounded technical review before committing to delivery, see Existing Project Rescue & Stabilisation.