Book a call

EngineeringSoftware built to last

Custom software →Web applications →Mobile apps →SaaS product engineering → Cloud applications →AWS development →DevOps & CI/CD →Cloud migration →

IntelligenceAI in production, not slideware

AI & machine learning →Generative AI applications →AI automation & integrations →Data engineering & analytics →

Experience & GrowthDesign and growth, one roof

UX/UI design →Brand identity →Marketing websites →Digital marketing & growth →Creative & campaign design →
We ship our own productsSeven of them, from GST books to gaming venues, built and run by this team. All 17 services Ways to partner with us Insights
Solution blueprint 03 · Mobile apps

Proof of delivery that works in a basement.

A delivery company runs on paper slips and a web page that fails the moment a driver loses signal. Disputes take days and the office learns of a failed delivery hours late. This is how we would build a driver app that works without a network and proves every drop.

A blueprint, not a client story: a problem we see often in logistics, and how we would solve it.

Talk about your version All blueprints
The situation · what hurts

Where itbreaks today

The symptoms that bring a team to us, in their own words.

  • Proof on paperSlips get lost, and a disputed delivery takes days to settle.
  • No signal, no appThe web page fails in basements, lifts and on highways.
  • Dispatch finds out lateA failed delivery reaches the office hours after it happened.
  • Lost at the gateDrivers phone customers to find the right entrance.
The solution · 10 parts, 9 flows

The blueprint,drawn

How the pieces fit together. Follow the numbers.

Driver appFlutter, offline-firstGWAPI GatewaySigned-in drivers onlyλDelivery APILambdaDBDynamoDBEach event applied onceOn-phone queueSQLite, orderedS3S3Photos and signaturesLOCAmazon LocationRoutes and geofencesEBEventBridgeDelivered, failed, lateDispatch consoleLive, by hubSNSCustomer messageSMS or WhatsApp123456789
  1. 1Driver app → On-phone queueEvery scan saved on the phone first
  2. 2On-phone queue → API GatewaySent in order when signal returns
  3. 3On-phone queue → S3Photos straight to storage
  4. 4API Gateway → Delivery APIVerified drivers only
  5. 5Delivery API → DynamoDBEach event applied exactly once
  6. 6Delivery API → Amazon LocationRoutes and the drop geofence
  7. 7DynamoDB → EventBridgeStatus changes published
  8. 8EventBridge → Customer messageThe customer hears at once
  9. 9EventBridge → Dispatch consoleDispatch sees it live
Blueprint 03 · Logistics
The decisions · 4 that matter

What we woulddecide, and why

Reliable, scalable, secure and sensible on cost: the choices that get there, with the settings beside them.

01Offline

Every scan saved before it is sent.

The app writes each scan, photo and signature to a local queue first, with its own id and sequence number, and only then tries the network. When signal returns, the queue drains in order and the server applies each event exactly once, so retries can never double a delivery.

The settings · offlinespec
Local store
SQLite queue, append-only
Identity
A unique id per event
Order
A sequence number per phone
Server
Idempotent writes, duplicates ignored
Conflicts
Last confirmed status wins, history kept
02Proof

Photo, signature, place and time, together.

A delivery is closed with a photo, a signature or a one-time code, the location and two clocks: the phone's and the server's. The drop is checked against a geofence around the address, and photos upload straight to storage with a short-lived link, never through the API.

The settings · proofspec
Evidence
Photo, signature or OTP
Where
GPS with a geofence check
When
Phone time and server time
Photos
Resized on the phone, presigned upload
Disputes
One page with every piece of proof
03Phones

Light on a cheap phone.

Drivers carry entry-level Android phones, so the app is built for them: location sampled by movement rather than a fixed timer, uploads batched, images resized before they leave the phone, and every screen usable with one thumb in the sun.

The settings · phonesspec
Target
Android 8 and up, 2 GB RAM
Location
Sampled by movement
Data
Batched uploads, small images
Screens
Big targets, high contrast
Languages
English and Hindi to start
04Release

Ship weekly without breaking drivers.

Every release is tested offline as well as online, rolled out to a small share of drivers first, and watched for crashes before it reaches everyone. Features ship behind flags, and the API keeps supporting the previous app version until drivers have moved on.

The settings · releasespec
Rollout
Staged on Google Play
Flags
New features off until switched on
Crashes
Reported with the screen and step
Versions
The previous app keeps working
Tests
Offline paths in every release
Design targets · agreed up front

What goodlooks like

Targets we would set together before the first line of work, and measure against after.

100%of scans kept with no signal, by design
< 1 minfrom drop to the customer message, once online
2 GBRAM phones fully supported
Weeklyreleases, staged

The plan

  1. 01Ride along with drivers and dispatch2 wks
  2. 02Design and a clickable prototype2 wks
  3. 03Offline core and sync3 wks
  4. 04Proof of delivery and routes3 wks
  5. 05Dispatch console and customer messages2 wks
  6. 06Pilot at one hub2 wks
Next · blueprint 04 · Digital marketingD2C fashionAds that pay back, and numbers the store agrees with.

Sound likeyour problem?

Tell us what is breaking. We reply within a working day with how we would approach your version of it.

Start a project All blueprints