02 / MOBILE RELIABILITY
Restoring trust in a product that had become unreliable
I took ownership late in a major mobile rebuild. Visually, it was a significant step forward, but reliability was still the bigger problem. I helped move the team from repeated hotfixes toward fixing the tracking system itself.
What was really happening: the tracking system
A failure anywhere breaks trust. The driver feels the same pain.
THE PROBLEM
Some of the hardest failures weren't obvious crashes. The app could simply stop tracking, and a driver might not realize anything was wrong until two or three days later, when trips turned up missing. Other issues showed up differently: trips starting late, splitting unexpectedly, routes appearing as straight lines, duplicate trips, backfill and sync problems, and inconsistent behaviour across devices and operating systems.
Across those failure modes, the user-facing question was the same: could drivers trust the app to capture reimbursable mileage consistently? The pattern was persistent enough to require a system-level response rather than another round of isolated fixes.
Underneath, It's a System
Different failures at different points create the same driver experience.
THE QUESTION WE NEEDED TO ANSWER
Where in the tracking journey is trust breaking down?
THE EVIDENCE
A GPS mileage product depends on a long chain of events: the device detects movement, the app recognizes a trip, tracking continues in the background, location data is captured, the trip ends correctly, it synchronizes, and mileage reaches the reimbursement platform. A failure anywhere in that chain looks identical to a driver: "the app didn't track my trip." The root causes were rarely the same twice.
Failures looked identical to drivers no matter their root cause. The fix had to address the system, not the symptom.
Key Decision
Stop treating reliability as a backlog of individual bugs. Start treating it as a system.
Option A: Patch the symptoms
One fix at a time
- Fast relief, one issue at a time
- Same failures recur under new names
- Doesn't address root causes
Option B: Treat it as a system
The whole chain, together
- Slower start, but addresses root cause across the chain
- Every stage gets diagnosed, not just the loudest ticket
Why: Failures looked identical to drivers no matter their root cause. Patching the loudest symptom would have left the underlying chain just as fragile. The fix had to change the unit of analysis from individual tickets to the reliability system itself.
WHAT I DID
The dependency became a product decision
We had been addressing issues through incremental fixes to a third-party tracking capability. Eventually the question changed from "what should we ask the vendor to fix next?" to "is continued dependency on this model the right long-term decision?" I built the case to bring the core tracking capability in-house, giving the team more direct control over reliability and iteration.
Before: Vendor Dependency
Request fix → wait → repeat.
After: Capability In-House
Direct influence. Faster iteration.
Android needed different attention
The failure profile wasn't identical across platforms. Rather than treating Android and iOS the same, I pushed for platform-specific expertise where the reliability problems were concentrated. Sometimes the product problem isn't another ticket; it needs different technical expertise.
Same product. Different failure profile.
Sometimes the product problem isn't another ticket; it needs different technical expertise.
Give drivers a fallback
Automatic tracking remained the ideal experience, but automation without confidence creates frustration. We introduced Manual Trip Start, letting drivers start a trip themselves rather than relying solely on detection. This wasn't an abandonment of automation. It was a fallback for when the normal path failed.
Ideal path
Fallback, if detection fails
Automation should make the normal path easier without leaving users helpless when the normal path fails.
THE TRADE-OFF
What Changed
WHAT I LEARNED
The product became more dependable because we stopped treating reliability as a backlog of symptoms and started treating it as a system.