We often hear something like this when we first speak to transport teams:
“The app works… it just struggles in certain areas.”
And on the surface, that sounds manageable. Every system has edge cases, and every app has its quirks.
The problem is, in transport, those “certain areas” aren’t rare. They’re part of the day job.
You’re constantly dealing with poor signal, busy routes, and areas of urban canyoning where connectivity drops in and out. That’s not an exception, that’s the reality your drivers are working in every day.
So, when an app depends on being online to function properly, those small issues don’t stay small for long. They show up at boarding, they slow drivers down, and they create friction with passengers. To make matters worse? It’s always really visible too.
That’s exactly what Coach USA were dealing with.
Their driver app was central to how they operated, especially when it came to ticket scanning. Technically, it worked. But in the moments that mattered most, particularly under the New York skyline where signal isn’t reliable, it started to fall over.
Drivers were left trying to work around it in real time, while passengers experienced the delays first-hand. At that point, it stopped being a background technical issue, and became a problematic part of the customer experience.
Unfortunately, the moments where it doesn’t work are the ones your customers remember, and the ones your drivers have to deal with. That’s where things start to feel uncomfortable internally too. Because the app was invested in as a means to improve operations on the frontline, not complicate them.
We worked with Coach USA to fix this. Our focus wasn’t on layering new features or trying to patch over the problem. It was about stepping back and asking a more fundamental question:
“What happens when there’s no signal?”
From there, the direction became clearer. We refactored the app with an offline-first approach, so the core functionality, including ticket scanning, didn’t rely on real-time connectivity. If the signal dropped, the app didn’t!
As a result of our solution, drivers could carry on doing their job, services could run as expected, and the experience stayed consistent for passengers. Once that dependency was removed, everything else settled down quite quickly.
Their drivers were able to trust the app again because it worked in the environments they actually operate in, not just the ideal ones. And, from a business point of view, fewer operational issues, fewer visible delays, and less conflict from teams on the ground was a massive win.
The app went back to doing what it was supposed to do in the first place: support the operations, not get in the way of them.
We see variations of this same issue crop up quite a lot in transport tech.
Apps are often designed around stable conditions, then gradually adapted to handle real-world complexity. Over time, that gap between “how it should work” and “how it actually works” starts to widen. Connectivity is usually right at the centre of it.
If your app works most of the time, but you’re noticing drop offs and increasing issues - it’s worth taking a closer look.
Not just analysing how often it fails, but where those moments sit in the journey. Are they happening in low-impact scenarios, or right in front of your customers?
Because if it’s the latter, whether through journey delays or passenger disputes, your team will already be taking the hit for it.
That’s usually a sign the app isn’t quite doing the job it was brought in to do. If you’re noticing problems like this, drop us a message to learn more about what we do. We can help you get it sorted.