Loyalty app maintenance for a drugstore chain

The chain's loyalty app had been built by an agency whose contract ended, and it arrived at us as a repository, a signing key, and no handover. It crashed reliably during points redemption — worst at month-end, which is exactly when promos run — the store rating sat at 2.8, and marketing had a roadmap of features that could not be built on something that couldn't hold still. The brief was blunt: make it stop crashing, then make it grow, and no, there is no budget for a rewrite.

Sole mobile developer responsible for the app, coordinating with the client's backend team, ongoing for over a year now. It's the classic inheritance job: every decision is archaeology first, and the original developers are available only in the sense that their commit messages exist, which for this codebase is a generous description.

I own the codebase, the release process — which did not exist as a process when I arrived — the crash triage, and the store listings. In practice I also own expectation management with marketing, since 'the app' and 'the promo calendar' are the same system as far as month-end is concerned, and someone has to say what the app can survive.

The first and best decision was refusing the instinct to rewrite and instrumenting instead: crash reporting revealed that around seventy percent of crashes traced to a single date-parsing utility used for points expiry, written for a date format the backend had since changed — one fix, shipped carefully, halved the crash rate in a week. I introduced CodePush for JavaScript-level hotfixes after a redemption bug at month-end promo cost us three days waiting on store review while support drowned; being able to patch within hours changed the job. Upgrades happen in stages behind a release branch with a device-lab pass first, because the user base skews toward older Android units that the emulator's optimism does not represent.

Promo dates are set by marketing and do not move — the app's riskiest moments are scheduled by someone else's calendar, so my release discipline exists entirely around theirs. Store review time is a real dependency for native changes, the user base's device floor is old and slow, and the original architecture's global-state habits mean some refactors I'd like are parked as deliberate debt, documented and scheduled rather than denied.

Crash-free sessions went from 92% to 99.5% over the first year, and the store rating climbed from 2.8 to 4.2, which marketing celebrates as their number and I permit that. Month-end promos stopped being support events — the last three ran without a spike in tickets — and the feature roadmap actually moved: two loyalty tiers and a pharmacy refill reminder shipped on the stabilized base. The refill reminder has the best retention curve of anything in the app, which suggests the most valuable feature was the one closest to what a drugstore is for.

The client's backend team met every date-format and API-contract discovery with patience and changelogs, which made the archaeology survivable. Their support lead's weekly ticket summaries were my real prioritization input for the first six months, and a QA engineer on the client side maintains the device lab that has saved at least two releases from shipping a startup crash to the app's oldest phones.