A route planning app is a stop list in the right order.
Anyone shopping for a route planning app already has the stops. Twelve addresses, one van, one day. What they do not have is the order, and the order is where the work is. Putting pins on a map is an afternoon. Deciding which pin comes third, once opening hours, a lunch break and a customer who has to be phoned first all exist, is a different problem. Constrain the vehicle too and you are into truck route apps, which add their own rules.
This page covers why stop order gets hard so fast, where travel times come from and what the APIs cap, what a stop carries besides an address, and what happens to the plan once the van moves.
See how fast the orderings growThe short version
Planning is a solver problem, navigating is a phone problem.
These are two different jobs, and most disappointment here comes from buying one and expecting the other. Planning takes a list of stops, a set of constraints and a table of travel times, and returns an order. Navigating takes one leg of that order and gets a driver down the street, with voice, lane guidance and rerouting.
Phones already do the second job well, and for free. Very little does the first job the way your round works. The constraints are yours: the site that only receives before ten, the customer who has to be called ahead, the stop that exists on alternate Tuesdays.
The stops are easy, the order is not
Ten stops can be visited in 3,628,800 different orders. Twelve stops in 479,001,600. Fifteen runs past a trillion. Nobody checks them all. A route optimization app is not a sorting trick, it is a search that has to stop early and settle for good enough.
The formal name is worth knowing, because it tells you what to search for. Google describes the Vehicle Routing Problem as finding optimal routes for multiple vehicles visiting a set of locations. With only one vehicle it reduces to the Traveling Salesperson Problem. The solver library then adds the constraints that make a round real: vehicle capacity, and time windows that require a visit inside a given period.
One detail in those docs saves an argument later. Minimising total distance across all vehicles and minimising the length of the longest single route are different objectives. The second is right when the goal is to finish the deliveries as early as possible. Choose the objective before the solver. A planner tuned to the wrong one produces routes drivers will push back on.
Google OR-Tools, the Vehicle Routing Problem
How big the ordering problem gets
Move the slider. The orderings are what a solver searches through. The legs are what a travel time matrix has to price.
3,628,800
possible orders
90
legs between pairs of stops
1 / 1
matrix calls at the 25 and 10 coordinate caps
Travel times are the part you pay for
To order stops you need the travel time between every pair of them, not just from the depot out to each one. Twelve stops is 132 ordered legs. Twenty five stops is 600. That is what a matrix API returns, and it is the line on the bill that grows fastest when a round does.
The caps are real and they shape the design. Mapbox limits its Matrix API to 25 input coordinates per request for driving, walking and cycling. Driving with traffic is capped at 10 coordinates, and at 30 requests per minute rather than 60. The response gives durations in seconds and distances in metres. A forty stop day does not fit in one call. You tile the matrix, cache what does not change, and accept that the traffic aware version gives the smallest window.
That cap is also the honest reason most planning happens in batches of about twenty. If drivers do sixty drops, the design that works is to cluster by area first, then order within each cluster. That is the shape a multi stop route planning app settles into. Static travel times are fine for planning tonight. Live traffic matters for re-ordering at eleven in the morning, and that is the call that costs.
A stop is a time window, not a pin
Geocoding turns an address into a point, and that point is often the middle of the building or the centre of a postcode. The place the driver actually stops is a loading bay, a side gate, a lay-by across the road. Store the arrival point as its own latitude and longitude, set the first time somebody gets it right.
Then there is time on site. A delivery route planner that models only driving hands you a day that does not exist. Twenty stops at eight minutes each is 160 minutes of standing still, and service time varies: a pallet into a dock is not a parcel through a letterbox. Hold a service duration per stop and let real arrival times correct it over the first month.
Windows and outcomes are the rest of the record. Every stop wants an earliest and a latest arrival, a priority, and a defined result when it fails: not in, refused, access blocked. Work whose length depends on who is doing it pushes you toward a field service scheduling app. There the visit is as long as the job and the parts on the van.
Once the van moves, the plan starts decaying
Turn by turn is the one part you should not build. Voice guidance, lane hints, live rerouting and offline map tiles are years of work that the phone in the driver's pocket already does. The normal design is to plan in your app and hand the next leg to Apple Maps or Google Maps with a link. The driver lands back on your stop list when the delivery is done.
It is worth being concrete about what an AI built app gives you here. In the project template Newly generates from, the map is drawn inside the app. It is Leaflet running in a WebView over OpenStreetMap tiles, with markers, and a route line drawn between exactly two waypoints by leaflet-routing-machine. That is a drawn route, not navigation. There is no voice, no rerouting and no follow the vehicle mode, and nothing in the template opens Apple Maps or Google Maps. The handoff is a link the generated app has to add, using the linking library the project already ships.
The other thing that changes when the van moves is the network. A plan fetched at eight is fine until the driver hits a valley with no signal and the stop list is a spinner. Decide early what lives on the device and what has to be live, which is the whole of keeping the route when signal drops. Queue each stop record locally and send it when signal returns.
What each way of planning a day actually gives you
| Option | Puts the stops in order | Knows the time windows | Live traffic | Fits your own stop data |
|---|---|---|---|---|
| Addresses typed into phone maps one by one | No | No | Yes | No |
| Spreadsheet plus phone maps | a person does it | in the planner's head | Yes | Yes |
| Consumer multi stop planner | Yes | sometimes | Yes | by import |
| Fleet routing platform | Yes | Yes | Yes | after setup |
| A planner you build | solver of your choice | Yes | if you pay for it | Yes |
Building one around your own round
Routing platforms are priced per vehicle per month and shaped around fleets with telematics hardware. A six van operation needs a fraction of that. It also needs the two or three things the platform will not do: the customer who must be phoned an hour ahead, the yard that can only be entered from the north, the stop that runs on alternate weeks. Those exceptions are why people go looking, and they are what a generic tool strips out.
Newly is an AI app builder. You describe the app, including the constraints your round has, and it writes a real React Native and Expo project you own. It runs that project on a cloud simulator while it builds, and uploads iOS builds to TestFlight through your own Apple Developer account. It costs $25 a month, there is no free plan, and Android goes to Google Play internal testing from the Deploy tab, or out as a standalone APK, which matters if your drivers carry Android. It ships no routing solver and no traffic feed. What it removes is the scaffolding between you and the two screens a driver needs.
Before any of that, settle the data model on paper. A stop has an arrival point, a window, a service duration and an outcome. A route is an ordered list of stops with a date and a driver. Most route apps that go wrong went wrong there, not in the solver.
Questions people ask about route planning apps
It takes a list of stops and returns the order to visit them in. Constraints shape that order: opening windows, vehicle capacity, how long each stop takes. Navigation is a separate job: most planners hand the next leg to the phone's own maps app.
Write down the round you actually run
List the stops, the windows, the ones that need a phone call first, and the order your best driver already uses. That list is the specification, and it is the part no off-the-shelf planner has.
Start building