The old SafiTrack mobile app worked. That was the problem. "Works" is a very low bar for something a sales rep opens thirty times a day while standing in a car park between calls.
We'd been hearing the same things from customers for months: too many taps to log a visit, loading spinners in places that should be instant, the app becoming useless in areas with poor signal. The feedback was consistent enough that we made the call to start over rather than keep patching.
What we learned from watching reps actually use the app
Before writing a line of code, we spent two weeks doing contextual research. Riding along with field reps and watching them use the app in real conditions. Three things stood out immediately.
First, most interactions happen under time pressure. A rep logging a visit is usually between two other things: just finished a meeting, heading to the car, trying to get notes down before the details fade. The app needs to get out of the way, not demand their full attention.
Second, connectivity is genuinely unpredictable. Even in urban areas, reps go in and out of weak signal zones all day. An app that requires a network connection to do basic things like view a contact or log a note is fundamentally broken for this use case.
Third, one thumb. People use phones with one hand while doing other things. Navigation that requires reaching to the top of the screen, or targets that are too small to hit accurately, add friction that accumulates over hundreds of daily interactions.
Offline-first from day one
The architectural decision that shaped everything else was committing to offline-first from the very beginning of the rebuild. Every action the app supports (logging a visit, adding a note, updating a deal stage, creating a task) works when the device has no connectivity. Changes queue locally and sync when the connection returns.
This sounds straightforward but the conflict resolution logic is genuinely hard. If a rep updates a contact note while offline, and their manager updates the same contact from the web dashboard at the same time, what wins? We spent a lot of time on the merge strategy and we still don't think we've nailed every edge case. But the baseline ("the app never tells you it can't do something because of network") we've achieved.
Reducing the tap count
Logging a visit in the old app took seven taps from the home screen. In the new app it takes two: tap the floating action button, confirm the visit. Everything else (which customer you're visiting, your GPS coordinates, the timestamp) is inferred from context or pre-populated.
We rebuilt the navigation hierarchy to put the actions reps do most (view today's route, log a visit, add a quick note) within one tap of wherever they are in the app. Less-frequent actions like editing company details or reviewing pipeline reports are still there, just one level deeper.
"It sounds like a small thing but when you're doing it twenty times a day, five taps versus two taps is enormous.". Customer feedback from beta testing
What's next
We're three months into the rebuild being in production and the metrics are moving in the right direction. Visit logging frequency is up 34% among active users, which tells us the friction reduction is real. Crash rates are down significantly, partly from the new architecture and partly from switching to a more predictable state management approach.
Next on the list: a smarter home screen that surfaces the right information contextually (nearest unvisited customers, deals with stalled activity, tasks due today) without the rep having to go looking for it. The goal is an app that feels like it knows what you need before you do.