A two-sided marketplace where the hard part is dispatch, not the map
A relocation and freight platform needed to connect customers who had something to move with drivers who had the right vehicle to move it — and do it live, with both sides watching the job progress on a map.
Think Uber, but where the vehicle has to actually fit the load.
Not the map. The map is the easy part.
The hard part in any two-sided marketplace is dispatch: when a job is posted, which drivers see it, in what order, and for how long? Get that wrong in either direction and the marketplace fails quietly.
Broadcast every job to every driver and they stop opening the app inside a week. Restrict it too tightly and jobs sit unclaimed while a driver two streets away never hears about them. Neither failure announces itself — you just watch both sides churn and guess why.
The second hard part is that two drivers will accept the same job at the same moment. Not occasionally. Constantly. And whatever happens next has to be correct every single time, because a double-assigned job means an angry customer, two angry drivers, and a refund.
A job posting filters on what’s non-negotiable — vehicle type and capacity, driver availability, service area — then ranks what’s left by proximity and rating. Offers go out in waves rather than to everyone at once: the best-matched drivers get a short exclusive window, then it widens. Drivers see fewer, more relevant jobs, and jobs still get covered.
When two drivers accept simultaneously, the winner is decided by a single conditional update at the database — assign this job only if it is still unassigned. One succeeds, one gets a clean “already taken.” Resolving this in application code instead would mean a race condition that appears once in a few hundred jobs and is close to impossible to reproduce.
Driver location is high-frequency and disposable — if a position update is lost, the next one is two seconds behind it. Job state is the opposite: accepted, collected, delivered must survive a reconnect, an app restart, a dead battery. So position streams over Socket.io and state changes go through regular requests that can be retried and verified. Mixing the two is how you end up with a job that’s complete on the driver’s phone and still in progress on the customer’s.
A parked truck emitting a position every second drains the driver’s battery and your bandwidth for no information at all. Updates fire on meaningful movement instead. Drivers run this app for eight-hour shifts — battery is a product feature, not an optimisation.
Funds are held until the job is confirmed complete, which protects the customer from paying for an undelivered load and the driver from doing the work and chasing the money.
Freight disputes are not an edge case — they’re a weekly operational reality. Every state change is recorded with a timestamp, so when a customer says the load arrived damaged and the driver says it didn’t, there is a record rather than an argument.
Built and shipped end to end as the sole mobile engineer — customer app, driver app, dispatch logic and live tracking — across native Android and iOS.
Marketplaces don’t fail on features. They fail on the quiet mechanics — who gets offered what, what happens when two people want the same thing, and whether the job’s state is still correct after someone’s phone dies in a tunnel. That’s the part worth getting right first.
Also built: OrderAt, a multi-vendor marketplace with native Android and iOS apps, carts, payments and multilingual support.
Reach out to discuss your project. I typically respond within 24 hours.