// Real-time dispatch & fleet platforms

When off-the-shelf dispatch
outgrows your operation.

Auction-style dispatching, real-time sync through SignalR, geospatial matching and background location that survives a real phone in a driver's pocket all shift — not just a demo on a desk. We built Carivio as a complete three-platform system in 4 months: today ~50 live vehicles, our own auction dispatching, our own financial engine. Your code, no vendor lock-in.

Request a dispatch platform Built on production numbers from Carivio and TaxiLight, not documentation theory.
// Where off-the-shelf dispatch breaks

Three moments when a packaged solution stops being enough.

Off-the-shelf dispatch systems (and cheap white-label apps) are a great start. The breaking point comes when your process — an auction model, specific billing rules, custom geospatial logic — doesn't fit someone else's data model, or when the vendor takes a cut of every ride forever.

Your process doesn't bend into someone else's product

A packaged solution has its own dispatch algorithm, its own data model, its own limits. An auction model for rides, custom pricing logic, or specific fleet states either won't fit at all, or only through expensive customization that's still not yours afterward.

Background location works in the demo, breaks in production

A demo runs for 20 minutes with the phone on a desk, the app in the foreground. Production means an 8-hour shift, the phone in a pocket, Android Doze mode and Xiaomi's MIUI battery manager killing the app without warning. Without per-OEM handling, kill detection and an offline queue, the driver's location disappears after 45 minutes.

Commission and vendor lock-in forever

Packaged platforms charge a percentage of every ride or a monthly per-vehicle fee indefinitely — and the data, the code and the relationship with drivers stay with the vendor. A custom platform is a one-time investment after which the system is yours.

// How we build it

Dispatch as an engineering problem with dozens of edge cases, not a demo.

Real-time dispatching and background location look simple until the app is actually in production. The real work is in what happens when the OS kills the app, two drivers respond to an offer in the same second, or a phone drops off the network for 3 minutes.

01

Auction dispatching, not a sequential queue

A ride offer goes out to all eligible drivers at once, the system picks the best one by a weighted score (distance, rating, response time) and broadcasts the result over SignalR. Faster and fairer than "offer one driver, wait, try the next" — but it requires idempotent winner selection, since two bids in the same second are normal traffic, not an edge case.

02

Real-time through SignalR, split by domain

Notifications, driver-dispatcher chat, ride status transitions and driver location run on separate hubs, not one channel. Otherwise location updates every 3 seconds flood the log and critical notifications get lost in the noise.

03

Push is the wakeup, SignalR is the truth

Push notifications wake the app even while it sleeps — but carry no business payload. That arrives over SignalR after reconnect. Mix the two and the app processes the same offer twice, showing up as mysterious duplicates in the UI.

04

Background location survives a real phone, not just a desk

Per-OEM handling (Samsung Sleeping apps, Xiaomi MIUI Autostart, Huawei Protected apps), a heartbeat that tells "app is dead" apart from "driver has no signal", and a local offline queue with exponential backoff that delivers GPS coordinates from an outage back idempotently.

05

One source of truth in the database, not three drifting states

Driver online/offline status, pending offers and active rides all have a single source of truth in the database. SignalR connection state and the app's local cache are replicas that always converge after reconnect — the dispatcher never sees a different state than the app.

06

Direct access to the architect

Dozens of edge cases around background location and real-time dispatching (OS kill recovery, permission flow, offline queues, timeout jobs) only surface for someone who's dealt with them in production — not a team building dispatch for the first time from a tutorial. You talk directly to the architect who holds the system in their head.

// Proof

Carivio: zero to a production fleet in 4 months.

Carivio is a complete three-platform dispatch system (driver app, customer app, dispatcher web) we built from scratch in 4 months. Today it runs ~50 live vehicles. We built our own auction dispatching, our own financial and billing engine with no dependency on Stripe or PayPal, and a Flutter driver app with over 128,000 lines of Dart code — with background location handled on real OEM phones, not just an emulator.

~50 vehicles live on Carivio's production fleet
4 months from zero to a complete three-platform system
128,000+ lines of Dart code in the driver app (Flutter)
Read case studies
// FAQ

Common questions about dispatch and fleet platforms.

// Contact

Tell us about
your operation.

We'll go through where your current dispatch or app hits its limit and design a real-time dispatching and background location architecture that holds up in production — not just in a demo. We'll reply within 24 hours with a concrete proposal.

Request a dispatch platform