Engineering · 7 min read ·
App rescue: taking over a build that went wrong
A surprising share of app projects arrive at a new team half-finished, undocumented, and two vendors deep. Rescue work is mostly diagnosis: deciding what to keep is more valuable than deciding what to rewrite.
Audit before you promise anything
Two weeks of structured review — build reproducibility, dependency health, crash data, test coverage, API contracts, store account access — will tell you whether you are looking at a refactor or a rebuild. Skipping this is how a rescue becomes the third failed attempt.
- Can a new engineer build and run it in a day?
- Crash-free rate and top five crash causes
- Who owns the store, cloud and domain accounts?
- Which parts have any test coverage at all?
Stabilise, then improve
The first release under new ownership should fix crashes and restore the release pipeline — nothing else. Users and stakeholders need to see the bleeding stop before they will fund the rebuild of anything.
Rewrite in slices
Replace module by module behind stable interfaces: auth, then data layer, then feature areas by crash and complaint volume. A big-bang rewrite hides progress for months and usually reproduces the original mistakes with newer libraries.
The takeaway
Diagnose, stabilise, then replace in slices. Full rewrites are the most expensive form of optimism in software.