Two Ways to Structure Dispatch 

Not every ride app is solving the same dispatch problem, and the real structures need different architecture. 

Kelebek is closed network dispatch, connecting hotels, drivers, and admins who already have a working relationship, organized into three panels that keep each role's daily tasks clear and repeatable. King Istanbul is open consumer booking. Any traveler can choose a vehicle type, book instantly or ahead of time, and pay inside the app without any prior relationship to the driver. A large scale ride hailing marketplace is a third real pattern. It operates across an entire city with thousands of independent drivers who have no prior relationship to the platform at all. Neon Apps has not built at that scale, since it carries a level of regulatory, insurance, and driver vetting overhead well beyond either of these two projects. 

Matching the structure to the actual relationship changes what gets built first: 

• Choose closed network dispatch when the business already has drivers or partners, and focus the build on coordination and record keeping rather than discovery 

• Choose open consumer booking when the product needs to attract both riders and drivers with no existing relationship, and invest early in trust signals and driver supply 

• Avoid building for large scale, multi operator ride hailing unless the regulatory and insurance groundwork is already part of the plan, since the technology is the smaller half of that problem 

Most founders in this category are closer to Kelebek or King Istanbul's scale than to a citywide operator's. The right first version usually reflects that honestly, instead of over building for a scale the business has not reached yet. 

How to Scope the First Version 

Most ride and dispatch apps fail on real time reliability, not on the booking flow itself. A first version that gets tracking and status updates right beats one with more features and a shakier live experience. 

• Pick closed network or open booking first, since Kelebek's three panel coordination and King Istanbul's consumer booking flow are genuinely different builds 

• Design the real time location and status system early, since a rider or an admin who cannot trust where a driver actually is loses confidence in the entire app immediately 

• Decide how money moves, in app payment, an internal balance ledger, or something else, before the booking screens get built, since that decision shapes the entire backend 

Teams that treat real time reliability as a detail to polish later usually end up rebuilding the location and status layer after launch. That happens once real trips expose the gaps a demo never showed. 

What a Realistic Build Timeline Looks Like 

Shipped examples in this category both took about three months despite serving very different audiences, and four stages make up that window. 

• Discovery and scope, where the team locks the network structure, the payment or balance model, and the real time tracking requirements before any screen gets designed 

• Core build, the largest block on the calendar, where booking or dispatch, live tracking, and the role specific panels or screens come together against that locked scope 

• Real time and load testing, run against actual concurrent trips rather than one test booking at a time, since sync issues only appear under real simultaneous use 

• Launch and monitor, the first few weeks live, when real trip volume tests whether the tracking and dispatch logic hold up outside a controlled demo 

Skipping real time load testing is the most common reason a dispatch system that worked perfectly for one trip at a time starts showing delays or sync errors. Several trips running at once expose problems a single test booking never will.