Inside Cabrooz: Building Real-Time Ride Dispatch That Still Works Offline

Cabrooz is a ride-hailing platform, passenger app, driver app, and admin dashboard, built for markets where connectivity isn't always reliable. That last part shaped almost every technical decision on the project.

Real-time is easy, real-time that degrades gracefully is not

Most ride-hailing tutorials assume a driver's phone always has a signal. In the markets Cabrooz operates in, that assumption breaks constantly. We built the ride matching system on WebSockets for live updates, but the harder problem was designing offline ride assignment, letting a dispatcher manually assign a trip to a driver when the automated real-time matching couldn't reach them.

What the architecture had to handle

• Live GPS tracking and route updates over WebSockets when connectivity is good
• A fallback dispatcher-assigned flow when it isn't
• Wallet-based payments that reconcile correctly even when confirmations arrive out of order
• Driver earnings and payout tracking that stays accurate across both flows

The part nobody asks about: driver trust

Ride-hailing platforms live or die on driver retention, and drivers don't stay on a platform where they can't see what they're earning. We built earnings visibility as a first-class feature, not an afterthought, because a driver who trusts the numbers is a driver who stays online during the hours that matter most for passengers.

Where this generalizes beyond ride-hailing

Any platform that depends on real-time coordination between two sides of a marketplace, deliveries, field service, on-demand anything, runs into the same core problem: the real world isn't always connected, and the system has to have a sane fallback instead of just failing. Designing for the offline case first, rather than treating it as an edge case, is what kept dispatch running at 98% completion rate even in patchy-connectivity conditions.