Driver app, offline-first
The day's stops are downloaded in the morning. Everything a driver does is recorded on the device and syncs when signal returns. Nothing is lost in a basement or a highway dead zone.
CASE STUDY
Example buildMobile AppDelivery Tracking App
Driver app with live location, proof-of-delivery photos and an owner-side status board.
- Type
- Driver app + owner board
- Build time
- 14–18 weeks
- Platforms
- Android and iOS, offline-capable
- Starts at
- ₹1,40,000*
This is an example build. Tavzuran is a new studio with no client work to show yet. This page describes how the project would be scoped and built — the same thinking you would get on a real one. Nothing here is a past client, and no number on this page is a result.
The price follows the feature list. The number above buys everything scoped on this page. Take features out and it comes down — the shortest route to a smaller number is a shorter list, and deciding what to drop is what the free call is for.
THE SITUATION
What's actually broken.
A logistics operator runs a fleet of drivers and finds out where a consignment is by calling the driver. Proof of delivery is a signature on paper that reaches the office days later, and disputes about whether something arrived are settled from memory.
The constraint that shapes the whole build is that drivers work in patchy network coverage. An app that only works online is not an app for drivers.
Finding a consignment means phoning the driver
Proof of delivery is paper that arrives days later
Delivery disputes get settled from memory
Apps that need signal are useless in a dead zone
VERSION ONE
What we'd build first.
Every item here earns its place by being something a real user would miss on day one.
Location tracking
Batched and sent periodically rather than streamed continuously — the difference between a phone that lasts a shift and one that dies at 2pm.
Proof of delivery
A photo and a recipient name, timestamped and location-stamped, attached to the consignment permanently.
Owner status board
Every active vehicle on one map, with delayed stops highlighted instead of buried in a list.
Customer tracking link
A link showing an ETA and no more. Customers do not need to see the driver's live position all day.
DELIBERATELY NOT IN V1
What we'd leave out.
Not because these are bad ideas. Because each one is designed better once the first version has told you something.
- Route optimisation. A genuinely hard problem; buy it from a specialist API later rather than build it now.
- Fuel, maintenance and driver payroll — a separate system.
- Barcode scanning at each hop, unless the operation already labels consignments consistently.
UNDER THE HOOD
How it's put together.
- Driver app
- React Native with a local database on the device and a sync queue — this is where most of the engineering effort goes
- Owner board
- React with a mapping library
- Backend
- Node with Postgres and PostGIS for the location data
- Photos
- Compressed on the device before upload; drivers are often on mobile data they pay for
HOW IT RUNS
Week by week.
-
01
Week 1
The consignment lifecycle and what a driver does at each stop, watched in person if possible.
-
02
Weeks 2–10
Driver app, offline storage and sync. The long stretch.
-
03
Weeks 11–15
Owner board, map and delay alerts.
-
04
Weeks 16–18
Two drivers run it alongside paper for a week or two.
THE HARD PART
Sync that survives a basement
Every build has one problem that decides whether the rest of it matters. This is that problem, written out.
An app that needs a connection is not an app for drivers. The whole build is shaped by that, and the cost sits almost entirely in one place: reconciling what happened on the device with what the server believes, after a gap of minutes or hours.
The failure that matters is not the obvious one. A phone with no bars is easy — you queue and retry. The expensive case is a connection that half works: the request reaches the server, the server records it, and the response never gets back. The driver sees a failure, taps again, and now the delivery is recorded twice. Every action therefore carries an identifier generated on the device, so a replay is recognised and discarded rather than duplicated.
Battery is the other constraint that shapes the code. Streaming location continuously kills a phone by mid-afternoon, and a dead phone records nothing at all — so positions are batched and sent periodically, which is less precise on the map and far more useful in practice.
BEFORE A PRICE EXISTS
What we'd ask you first.
A quote given without these answers is a guess. These are the questions that actually move the number.
- 01How many drivers, and are the phones theirs or yours?
- 02Where does coverage actually fail on a normal route?
- 03What counts as proof of delivery today, and who asks for it?
- 04Do you own the vehicles, or is it a contracted fleet?
- 05How are disputes about non-delivery settled at the moment?
AFTERWARDS
How we'd know it worked.
Agreed before the build starts, so there is something to judge it against other than whether it looks nice.
- Over ninety-five per cent of stops are recorded on the device the day they happen.
- Every completed delivery has a photo and a name attached to it.
- A delivery dispute is settled from the record rather than from memory.
- A driver's phone still has charge at the end of a shift.
BEFORE YOU START
Worth knowing.
Offline-first roughly doubles the effort of a driver app compared with an online-only one. It is also the difference between drivers using it and drivers going back to the phone call. Budget for it deliberately.
Websites and apps start at ₹20,000*. Final pricing depends on features and project scope. Third-party costs — cloud hosting, domains, external libraries, APIs, app-store fees and any other paid service — are billed separately and are not included.
KEEP LOOKING
Other example builds.
First Version
Booking & Scheduling, Version One
Ships in weeks, not months: online booking, reminders and payments for a local service business.
Read the case study SaaS ProductSaaS Subscription Starter
Sign-up, workspaces, plans and recurring billing — the unglamorous half of a SaaS product, built once and properly.
Read the case study WebsiteBusiness Website That Converts
A fast, mobile-first site that turns visitors into enquiries — and that you can edit yourself.
Read the case studyWant this built for your business?
Tell us what you're thinking. We'll figure out the next step together.
Free 20-min idea call · No obligation