The dispatcher panel for a septic service company took weeks to build, because it required learning somebody else’s trade first. The driver app took around 30 hours, because it is not a separate product but a slice of the same system: the same data, narrower permissions and an interface rewritten for a thumb. The driver gets the working day on a phone, navigation to the customer’s gate and a place to settle the cash he collected.
Tidly is an in-house RapidLogic project, a two-sided platform connecting homeowners with waste collection companies. We described the customer side in the Waste collection marketplace case study and the back office side in the Dispatcher panel for septic companies. This entry covers the third window onto the same set of data, the one that travels in the truck cab.
The driver app is not a separate system. It is a slice of the dispatcher panel: the same jobs, the same statuses and the same price lists, shown in a vertical layout and trimmed to the scope a driver needs to complete a run. Price matrices, company settlements and customer data belonging to other trucks are simply not there, because none of it is required to drive a route.
That is where the whole argument of this case study comes from. A second app in a system costs a fraction of the first one, provided the data architecture was designed once and designed properly. The panel required weeks of market analysis and interviews with carriers. The driver app closed in roughly thirty hours.
Very few companies in this trade run it properly. Our interviews put it somewhere between one and five percent of the market. Such a company prepares a solid list in a spreadsheet and sends it to drivers over a messenger. The rest take jobs by phone all day long, write them on paper notes and hand those notes to drivers in the morning.
The trouble starts after eight in the morning, because the working day never stays the way it looked on the note. Somebody cancels a pickup, somebody else asks for an urgent visit the same day. The owner or the dispatcher takes that call, then rings the driver and asks him to swing by a particular address. The driver adds it to his own note, at the wheel, mid route.
Designing this view, we started from what a driver actually does, rather than from what the panel is able to display. Six areas were left. Each one is below, together with screens from the working app.
The first screen after logging in is a dashboard with a monthly calendar showing the number of jobs on each day. Below the calendar the driver sets his availability for the day, which the dispatcher panel uses when distributing work. Further down runs the job list with address, status and order source, and every row carries three actions available without opening the job: navigate, edit and view.
Changes during the day no longer require a phone call. When the dispatcher adds a job, the driver gets a notification and the row appears on the list. The job can land close to another order in the same area, because the panel takes into account completion status, availability and the daily run limit of a given truck. We described the zoning mechanics in the dispatcher panel case study.
The daily dashboard: a calendar with job counts, an availability switch and a list carrying navigate, edit and view actions.
Notifications replace the call from the dispatcher. Every new job has an entry here, with address and amount.
The detail view gathers everything the driver needs to know before entering the property. At the top the ordered service with tank capacity and any extras, for instance a surcharge for a longer hose. Then whether the pickup is contactless and whether the property has a quick coupling, the notes written by the customer and finally the total to settle.
The section below holds customer details with a phone number that dials or texts in a single tap, plus the billing data. None of it has to travel through the office any more, because it rides along with the job.
The ordered service with surcharges, quick coupling information, customer notes and the total to settle.
Contact and billing details. Calling and texting work in one tap, with no number to copy out.
This element looks trivial until you look at who actually drives these trucks. Waste collection work is not pleasant, so applicants are scarce and it is easier and cheaper for companies to hire drivers from abroad. Two barriers show up at once: knowledge of local geography and communication, because reaching such a driver means a phone call and an effort to be understood.
In the app every job address carries a map and a button that launches navigation, exactly as in ride hailing apps. Approach notes sit above the map, so information about a dog on the property or an entrance from the back of the plot arrives before the truck does, not after. In counties like Wieliczka, where house numbers follow no obvious order, that is the difference between a run and a search party.
Approach notes above the map and navigation behind one button. The driver does not have to call and ask for directions.
Cash handling in this trade looks the same as it did thirty years ago. Drivers collect money from customers, give change and carry the takings back to the office. With five, ten or fifteen trucks somebody eventually makes a mistake, and in the evening the till comes up short with no way to trace it to a particular run.
In the app a single job carries a payment method, a payment status and a completion status, and the driver changes all three from the phone. With online payment the status arrives on its own. With cash the driver logs the amount he collected against the job, so in the evening he should hand over exactly what the system shows. The flow of money stops being a matter of trust and memory, because every unit of currency has its own row.
Payment method, payment status and completion status. The driver changes all three without contacting the office.
Letting drivers create jobs looks like a breach in the division of roles, until you count how these companies really look. Not every one of them has a dispatch desk. Tidly also serves one, two and three person operations, where the customer rings the driver directly because he kept the number from the last pickup.
Without a system such a job lands in a notebook and has to be retyped into a computer in the evening. In the app it takes three taps and a minimum of data, a date and a note, because the screen was designed to be operated in the cab. Price, the invoice flag and the address with map verification wait in the second tab and can be filled in later, at a computer or during a stop between runs.
Step one is the minimum that can be typed in a cab: a date and a note.
Step two gets completed later: price, invoice and an address checked on the map.
A job keeps changing after it is accepted, so the driver can edit it. The customer calls to say there is a dog on the property or that the entrance runs from the field side, and the driver adds that as a note, changes the date or the status. The same change is immediately visible in the office panel, because both apps work on one set of data.
The last screen is a history of the driver’s own jobs with a search box and filters by source, status and date range, plus a switch between list and map. The driver can check when he last visited a given address instead of calling the office to ask.
Editing a job from the field. A note about a dog or an approach stays in the system, not in the driver’s head.
A history of the driver’s own jobs with filters and a map view, available without asking the office.
The driver app is a progressive web app, which means it runs in the phone browser while installing and launching like a normal application. The choice followed from the stage of the project. While you are still checking whether an idea will land at all, a native release on two operating systems means a separate project, separate releases and a review process in two stores. We needed this on the same day the panel existed.
As a result the app was built as a natural extension of the web side, at a fraction of the cost of a separate mobile project. Installing it on a driver’s phone comes down to opening a link and choosing add to home screen. From that moment the icon sits next to the other apps, and the company pays nothing for distribution and waits for nobody to approve a release.
A native app was planned for the case where the system caught on and a need appeared, working without coverage for example. Until then it would have been money spent on something nobody had verified yet.
How far the testing went. The app went through hallway testing and installation on devices belonging to family, friends and two professional drivers from the transport trade. There was no production rollout in a septic service company, because the commercial development of Tidly was paused, which we cover in the marketplace case study. We are reporting exactly as much as we checked.
The scope was trimmed on purpose, down to what a driver needs to complete a run and settle a job. Below are the things such apps sometimes carry and ours does not.
This case study has no market analysis phase of its own, because all of that work happened earlier, on the operations panel. Below is the course of this particular part.
We have no results from a rollout at a paying carrier and we are not going to invent any. What we do have is a measured amount of work and a working product, and that is enough to show what a second app costs in a well designed system.
Waste collection sounds like a narrow niche, yet the driver app solves a problem that looks identical in every company with people in the field. Somebody receives a task list in the morning, drives to an address he does not know, needs the full picture before stepping onto customer ground, changes a status once the work is done and settles money. Exactly the same thing happens in technical service, in deliveries and in installation work.
The conclusion for an owner is not a feature list, though. If company data lives in one place, every further view onto it costs a fraction of the first one. The office panel took weeks, the driver app thirty hours, because nothing had to be designed from scratch. It works just as ruthlessly in reverse: companies keeping every process in a different tool pay for the same integration several times over.
Today we would build it faster still. The same scope delivered with AI-assisted engineering, which we show in the Fortress and Invoice Automation case studies, takes roughly three times less time and money, and comes without the limits of a no-code platform.
Cash handling in this trade is a story from thirty years ago. Drivers collect the money, give change and carry the takings to the office, and with ten trucks somebody eventually makes a mistake and the till comes up short in the evening. In the app the driver logs the amount against the job, so the till either adds up or you can see straight away which run it went wrong on.
A task list on a phone, navigation to the customer address, a status change and cash settlement is the scope we built into Tidly in roughly thirty hours. A free digital audit will show what such an app could look like for you and which system it could stand on.
Book a free digital audit