Mosaic
Reducing fleet-wide POS ANR and crash incidents from several per day to a few per week.
I stabilized a live POS across 1,000+ locations and 2,000+ devices while stores and releases kept running. I connected customer feedback with telemetry, then migrated targeted JavaScript/WebView workflows into Flutter. Over six to eight months and 10+ production releases, approximate fleet-wide ANR and crash incidents fell from several per day to a few per week.
Project evidence
- Daily → weekly
- fleet-wide ANR and crash incidentsApproximate incidents declined from several per day to a few per week over six to eight months.
- 1,000+
- store locationsProduction fleet also spanned 2,000+ devices.
- 10+ releases
- production delivery during recoveryReliability work and incremental migration shipped over six to eight months.
- Login first
- then heavy end-of-day calculationsTargeted JavaScript/WebView flows migrated to Flutter.
01 / Ownership close to the customer
Connect store reports to the failing runtime paths.
I worked on an active POS used across 1,000+ locations and 2,000+ devices, including low-end Android hardware. Recurring ANRs and crashes in JavaScript/WebView workflows affected journeys stores depended on, so recovery had to fit ongoing operations.
I handled customer support directly and made the failing journeys observable with Firebase instrumentation and JavaScript diagnostics inside the WebView. Connecting store reports to ANR telemetry and runtime traces showed which workflows were disrupting users and where a Flutter replacement would address the cause.
02 / Migration judgment
Start with low-risk login, then tackle end-of-day calculations.
I chose the lower-risk login flow to establish an incremental migration path first. I then moved the calculation-heavy end-of-day workflow from JavaScript/WebView behavior into Flutter, preserving the required on-device processing.
I kept each change bounded to a workflow the evidence justified. That let stores continue operating and the team keep shipping while I improved the application incrementally.
System model
A production reliability loop
Instrumentation and user evidence identify an improvement area; profiling narrows the cause; focused native replacements ship; production evidence informs the next step.
Production feedback loop
- 01Production signals
Firebase · runtime errors · user feedback
- 02Profile and debug
Performance · responsiveness · runtime stability
- 03Select the improvement area
WebView and legacy boundaries
- 04Native Flutter flow
Bounded replacement and refactor
- 05Production release
Continue product delivery
- 06Observe the result
Use real-world evidence for the next cycle
Connections
- Production signalsProfile and debug
- Profile and debugSelect the improvement area
- Select the improvement areaNative Flutter flow
- Native Flutter flowProduction release
- Production releaseObserve the result
- Observe the resultProduction signals
03 / The production result
Reduce incidents while continuing normal delivery.
I shipped the recovery work through 10+ production releases over roughly six to eight months. Approximate fleet-wide ANR and crash incidents fell from several per day to a few per week as the fixes and targeted migrations reached stores.
I continued using customer feedback and Firebase instrumentation to guide investigations across releases. The result came from connecting support, diagnosis, migration decisions, and production delivery as one responsibility.
Discuss the work
Bring me the next product problem.
I bring product judgment, hands-on leadership, and the engineering depth to take an important problem from the first decision through release. Let’s talk about what you want to build or improve.
The source code is proprietary to Shuru Technologies. I can discuss my responsibilities, profiling and debugging approach, technical decisions, trade-offs, and outcomes without disclosing confidential material.