A waste collection app is a list of bins and a record of what happened at each one.
A waste collection app is not a delivery app with the parcels taken out. A delivery either arrives or it does not. A collection round passes the same addresses every week, so the interesting question is never where the truck went. It is what happened at the bin: served, never presented, wrong material inside, no access, lid jammed open. That is a different data model from the one most route planning apps start with.
This page covers what a round actually is, what the crew's app has to capture at the kerb, what happens when the signal drops halfway down a lane, and where the app stops being any kind of legal record. Including the parts we could not verify.
See what each outcome has to recordThe short version
Anything can hold the round. The work is in the bins you did not empty.
The crew already knows the round. Same streets, same day, same order, and a printed sheet holds all of it. What the sheet cannot do is answer a question three days later: was number 14 served at 07:42, or was the bin never out? With no record, the safe answer is a return visit, and return visits are where the money goes.
So the thing worth building is not navigation. It is a fast way to mark an outcome at every stop with a time and a position attached, and a way to see those outcomes back at the depot before the phone starts ringing.
A round is a service list, not a delivery list
A delivery route is built fresh each morning out of orders. A collection round is a standing list: the same properties, the same day, the same sequence, week after week. The app holds that list rather than inventing it. Worth carrying on every property: address, container ID, service type, which week it falls in where collections alternate, which side of the road it is on, and whether it is an assisted collection where the crew fetches the bin from the property itself.
Order matters, but not the way it does in logistics. The sequence of a round is a settled thing the crew knows and the truck's turning circle enforces. A bin collection route app that resequences the round each morning because an algorithm found a shorter path is how you lose the driver in week one. Genuine optimisation belongs where stops change daily, which is the job of a multi stop route planning app. Here, let the crew edit the order and then leave it alone.
What does change is the tipping. A truck fills, drives to the transfer station or depot, empties and comes back, so a round is several passes with dead running between them. Any time estimate that ignores the tip trip is wrong by however long that round trip takes. Model the tip as a stop with its own timestamp, because it is also where the load gets weighed.
What the app records at the bin
This is the whole product. Each stop produces one record: what happened, when, where, which vehicle, which crew, and a photo where a photo settles the argument. Keep the outcomes as a short fixed list rather than a free text box. The one screen that decides whether a waste management driver app survives contact with a wet Tuesday is this one, and a driver in gloves will tap five buttons but will never type. The record at a collection stop has a lot in common with what a proof of delivery app captures, with one difference: nobody signs for an empty bin, so the evidence has to be the time, the place and the picture.
The time and the place come from the device. In a React Native and Expo project, the location API returns a position object with a coords field holding latitude, longitude and accuracy, and a separate timestamp field, which the documentation describes as the time the position information was obtained, in milliseconds since epoch. Foreground access needs NSLocationWhenInUseUsageDescription on iOS and ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION on Android. Recording position while the screen is off is a different and harder ask: that is background access, which needs the Always authorisation on iOS and ACCESS_BACKGROUND_LOCATION plus a foreground service on Android.
One question deserves a straight answer, because everything above depends on it: can an app you build yourself record a stop as served, with a timestamp and a location? Here is what we actually saw. We did not run a build that did it, so treat this as unconfirmed rather than tested. Newly writes React Native and Expo projects, and the location API just described is the standard way this is done in that stack, so a stamp taken the moment the crew taps a button is ordinary work. The v2 documentation lists the native packages that ship pre-installed and a location module is not among them, while a separate page says everyday permissions including location need no special approval and are prompted at runtime. So expect foreground capture to be straightforward, and confirm background tracking yourself before you promise it to anybody.
Expo Location, LocationObject fields and permissions
Try it
What each outcome has to record
Pick what happened at the bin. The fields are the record. The line under them is the reason the record is worth capturing at all.
Captured at the stop
Time, position, round, vehicle, crew
Nothing else happens. This is most of the day, so it has to be one tap with a glove on.
No signal is the normal case, not the edge case
Rounds run down lanes, through estates with thick walls and along the back of industrial units. The connection will drop. If the app needs the network to record a stop, the crew stops using it on the second morning and goes back to the sheet.
The design that survives is local first. Write the outcome to the device, show it as recorded immediately, and sync when there is signal. Two details decide whether that actually works. The record needs an identifier generated on the device, so a retry cannot create the same stop twice. And the crew needs to see what is still queued, because silence looks exactly like success until the depot asks where the data went.
Satellite positioning is not the mobile network, which is the useful half of this. A phone can still fix a position with no data connection, though it may take longer without the network to help it. The timestamp and the coordinates of the stop are real either way, and only the upload waits. What to do about conflicting edits, and how long to hold a queue, is the subject of a route with no signal.
Where the app stops and the legal record starts
An app full of timestamps looks like a compliance record. It is not one, and treating it as one is how an operator gets into trouble. Duties around driving hours sit with the carrier, and they are met by the records the rules actually name, not by whatever your app happens to store.
For local rounds the short haul exception is often the relevant one. It applies to a driver operating within a 150 air mile radius, which the rule gives as 172.6 statute miles, of the normal work reporting location, who returns there and is released from work within 14 consecutive hours. It relieves the driver of the record of duty status paperwork and puts the obligation on the carrier instead: keep accurate time records showing the time the driver reports for duty each day, the time released from duty each day, and the total hours on duty each day, and retain them for six months.
Two things follow for the build. Your stop times are operational data. They answer resident queries and they help plan the week, but they do not replace duty records and they do not decide whether a driver is legal. And if your times and the official records disagree, you have manufactured a problem, so decide early which system is the authority and keep the other out of that conversation. Whether any of these rules apply to your vehicles at all depends on the operation and the jurisdiction. That is a question for whoever runs your compliance, not for a build tool and not for an AI.
What each option gives a crew
| Option | Holds the standing round | Timestamped proof of service | Reason a bin was skipped | Works with no signal |
|---|---|---|---|---|
| Printed round sheet | Yes | No | if the crew writes it down | Yes |
| Phone camera and a group chat | No | photo time only | buried in the thread | No |
| Consumer navigation app | as a stop list | No | No | map only |
| Waste management platform | Yes | Yes | Yes | depends on the product |
| An app you build | Yes | Yes | your own list of reasons | if you design for it |
Building one around your own rounds
Waste management platforms are built for large operations and they arrive with a firm opinion about how a round should work. Plenty of operators need a fraction of that, plus two things the platform will not do: an alternate week pattern that does not match the standard one, and a reason code that exists because of a single awkward site.
Newly is an AI app builder. You describe the app, including the outcomes your crews actually record, and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month, there is no free plan, and iOS builds go through your own Apple Developer account. It is not a waste management system and it knows nothing about your rounds until you tell it.
Start with one artefact: the outcome list. Write down the five or six things that can happen at a bin, what each one has to capture, and who deals with it afterwards. Everything else here gets easier once that list is settled, and it gets expensive to change once crews have learned it.
Questions people ask about waste collection apps
It holds the standing round rather than a day's stop list, and it records an outcome at every property: served, not presented, contaminated, no access, container damaged. Each outcome carries a time and a position. Navigation is the smallest part of the job, because the crew already knows the streets.
Write down what can happen at a bin
List the outcomes your crews actually see, what each one has to capture, and who picks it up afterwards. Then build the round around that list.
Start building