Before estimating changes to an existing app, confirm that the team can build it, understand its dependencies and identify the systems it relies on. A feature estimate made without that context can hide substantial recovery work.
Reproduce the baseline
Obtain the repository, documented setup and appropriate access through approved channels. Build the current version in a clean environment and compare it with the released product. Record missing configuration and undocumented manual steps.
Do not assume the latest branch is the release source. Establish which code and configuration correspond to the version users actually have.
Map operational dependencies
Identify backend services, analytics, payment systems, push infrastructure and third-party SDKs. Record ownership and access requirements without copying secrets into shared documents. Note dependencies that are obsolete or difficult to maintain.
Clarify who controls release accounts and signing workflows. Development progress can be blocked by an ownership problem even when the code change is straightforward.
Review risk around the requested change
Inspect the specific area of the app that will change, including tests, error handling and related user journeys. Separate required work from optional modernization. A takeover should not become an unbounded rewrite unless the evidence supports that decision.
List known defects and unresolved questions. An estimate can include assumptions, but those assumptions should be visible and revisited when discovery changes them.
Agree on acceptance and handoff
Describe what success looks like on real devices, how the work will be reviewed and who approves release. Include documentation and operational ownership in the deliverables.
The result of this inspection is a more credible scope: what can be delivered, what must be repaired first and where uncertainty remains. That is more valuable than an early precise-looking estimate that collapses as soon as implementation begins.