A multi stop route planning app is only as good as the order it picks.
Twelve addresses, one van, one driver who wants to be finished by six. A multi stop route planning app is the software that decides which address comes first. That decision is worth more than the map underneath it. Drawing roads between two points is a commodity, shared with route planning apps of every kind. Choosing the sequence is where the cost sits, and it is the first thing free tools cap.
This page covers why the order is brutal arithmetic, what an optimisation API decides for you, why a stop is a time window rather than a pin, and what fifty stops do to a phone with no signal.
See the arithmetic behind the orderThe short version
Drawing the line is cheap, choosing the order is not.
Two separate things happen inside a multi stop route planner. Something decides the sequence, and something draws the roads between each pair. The second has been sold by the request for over a decade. The first is a search problem that grows far faster than the stop count, and it is the part you are really buying.
That split tells you what to build. If the driver already knows the order, you need a list, a handoff to a map app and a record of each door. If the order changes every morning, you need an optimiser, and you have to describe your day in terms an optimiser can read.
The order is arithmetic, and the arithmetic is brutal
Ten stops can be put in 3,628,800 different orders. Twelve stops can be put in 479,001,600. That is plain factorial arithmetic, and it is why nothing worth using tries them all. An optimiser searches the space and returns a good answer rather than a provably perfect one. For a working round that distinction never matters.
The second number is the cost of looking. To compare two orders you need the travel time between every pair of points. A depot plus ten stops means one hundred and ten directed pairs. Matrix services either bill by the pair or cap how many pairs one request may hold, and the count grows with the square of the round.
Then there is the order your driver already uses. The human sequence carries things no optimiser knows: the gate that is blocked at lunchtime, the street that is impossible during the school run. Software that overrides all of it on day one gets switched off in week two. Software that proposes an order, lets the driver drag two stops around and remembers the change, gets used.
Try it
How big the ordering problem gets
One van, one depot, a day of drops. Move the stop count and watch two numbers grow: the orders a planner could choose from, and the pairs of points something has to measure first.
3.6 million
possible orders for those stops, leaving from the depot
110
directed pairs of points to measure before anything can be compared
The left number is why nothing tries every order. The right number is why the measuring grows with the square of the round, and why the bill does too.
What an optimisation API decides, and what you still describe
A directions API takes an order you supply and returns the roads. An optimisation API takes a set of places and returns an order. They are different products at different prices, and confusing the two is the most common planning mistake in this category.
Mapbox documents the shape clearly enough to design against. Its Optimization v2 API is asynchronous: you post a routing problem, get an identifier back, then poll for the solution. A problem holds vehicles, which carry a start and end location, capacities, and working hour windows with optional breaks. It holds services, which are plain visits, and shipments, which are collected in one place and dropped in another. The documented ceiling is 1000 locations per routing problem.
Read that list again as a specification for your own data. Every field the optimiser accepts is a field somebody has to fill in: how long each stop takes, when the site will accept a delivery, what the van can carry, when the shift ends. The API is the easy half. Saying what your day is in that vocabulary is the work.
A stop is a time window, not a pin
The record behind each stop decides whether the plan survives the morning. A stop sequencing app that knows only where the pins are will produce an elegant order and a bad day. A usable stop carries an arrival window, a service duration, an access note, a contact number and a state: pending, done, failed, moved to tomorrow.
Service duration is the field people leave out, and it is the one that wrecks the schedule. A drop that takes two minutes at the kerb and one that takes twenty on the fourth floor are the same pin on a map. Optimisers accept that duration as an input. They cannot guess it, so somebody measures it once and keeps it with the customer.
A stop also has to close properly. Something records who took it, when, and with what evidence, which is the job of a proof of delivery app. The person driving needs a view built for one pair of hands, which is what a delivery driver app is for. Keep those as their own records rather than flags on the route. The route is a plan and it changes all day. What happened at a door does not.
The plan also has to be rebuilt from where the van is now. A perfect route made at eight is worth less than a decent replan at half past eleven, after two failed drops and a closed road.
Fifty stops on a phone, half of them with no signal
A fair question about any generated app is how many stops the list can hold before scrolling turns rough. We have not measured that on a Newly build, so treat any specific number, including one an AI hands you, as unverified. What can be said is where the limit comes from, because it is not really the stop count.
React Native lists are virtualised: FlatList mounts a window of rows around the visible area instead of all of them. By default that window is twenty one viewports, ten above and ten below the one you can see, and ten items are rendered on first paint. When it cannot render fast enough you see blank space where rows should be. For fixed height rows the documented fix is getItemLayout, which removes the asynchronous layout measuring altogether.
So the useful answer is about row weight, not row count. Two hundred plain rows at a fixed height scroll fine. Fifty can stutter if each one draws a map thumbnail and recalculates a distance on every render. Test on the oldest phone your drivers carry.
Then there is the signal. Rounds run through basements, loading bays and underground car parks. An app that fetches the next stop on demand is useless in all of them. The day gets downloaded once in the morning and written back when the bars return. That turns the route surviving a dead zone into a storage and sync question, not a mapping one.
What each way of planning a route with many stops gives you
| Option | Stops per route | Picks the order | Time windows | Usable with no signal |
|---|---|---|---|---|
| Google Maps app | 9 plus your start | No | No | downloaded area only |
| Spreadsheet plus satnav | as many as you type | the planner does | in the planner's head | No |
| Web route planner | hundreds | Yes | usually | No |
| Fleet platform, per seat | hundreds | Yes | Yes | varies by vendor |
| An app you build | what your API allows | with an optimisation API | Yes | if you cache the day |
Building one around the round you actually run
Route planners are priced per driver per month and shaped around a generic day. That works until your day is not generic: a customer who has to be phoned an hour ahead, a stop that only exists on alternate Tuesdays, a run that has to finish before the school gates open. Those rules are the reason your round is still a problem, and they are what a generic tool asks you to drop.
Newly is an AI app builder. You describe the app, including the rules your round really has. It writes a real React Native and Expo project you own and runs it on a cloud simulator while it builds. iOS builds go to TestFlight through your own Apple Developer account. It is $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. It is not a routing product either: the optimisation service and the map data stay services you choose and pay for.
A sensible first version is smaller than people expect. One screen with today's stops in order, a button that hands the next address to the phone's own map app, a note and a photo per stop, and the whole day held on the device. Run that for a fortnight and you will know which constraints really matter.
Questions people ask about multi stop route planning
It holds the places one vehicle has to visit in a working day, decides or accepts an order for them, and guides the driver through that order stop by stop. Routing between two points is the commodity part. Choosing the sequence, and holding what each stop needs, is what separates it from a navigation app.
Describe the round your driver actually does
Write down the stops, the windows, the service times and the things only the driver knows, then build the planning around those rather than around a generic day.
Start building