Logistics
Proof of delivery for a courier company
A courier company assigns stops to drivers each morning. The driver sees today's route in order, marks each stop delivered or failed with a photo and a reason, and the customer gets a tracking link. Dispatch sees every van's progress live.
Automatically generated draft
Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.
Section 01 · What has to work
Drivers complete assigned morning stop sequences sequentially with photographic proof while dispatch monitors live van progress and customers track links.
Section 03 · Screens
Every screen, and what it is for.
- ›Driver Route View — driver, views today's stop sequence and updates statuses, map rendering must be instant.
- ›Stop Detail View — driver, captures delivery photo and failure reason, camera launch must be instant.
- ›Dispatch Live Map — dispatcher, monitors all active van locations and route progress, map refresh must be instant.
- ›Customer Tracking View — end customer, views real-time delivery ETA and status, page load must be instant.
Anything not on this list is not in version one. That is what keeps a fixed price fixed.
Section 04 · The data model
What it stores, and who can read a row.
stops
id uuid, route_id uuid, sequence_order int, address text, status enum(pending, delivered, failed), recipient_phone text, delivery_notes text, failure_reason text, photo_url text, completed_at timestamptz
Access · Drivers read assigned route stops; customers read their own stop via public token.
routes
id uuid, driver_id uuid, assigned_date date, status enum(draft, active, completed), created_at timestamptz
Access · Assigned drivers and dispatchers read routes for their operating depot.
drivers
id uuid, user_id uuid, name text, phone text, current_latitude numeric(10,8), current_longitude numeric(11,8), last_ping_at timestamptz
Access · Drivers read own profile; dispatchers read all drivers within their depot.
Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.
Section 05 · States
pending → delivered | failed
Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.
Section 06 · Where this breaks
What bites products like this one.
Drivers lose cellular coverage mid-route, preventing photo uploads and stop status updates.
Queue stop mutations locally in SQLite and sync automatically when network connectivity returns.
Large uncompressed mobile camera photos consume device storage and fail on slow cellular uploads.
Compress and resize images on device to maximum 1080p before transmitting to object storage.
Section 08 · Deliberately left out
What version one does not do.
- ×Dynamic in-day route re-optimization — complex to build, adds cost in v1; static morning assignment is sufficient.
- ×Customer signature capture on glass — adds UI friction on mobile; photo proof and GPS coordinate match are enough.
This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.
Still open
What we would ask before quoting.
- What is the maximum acceptable photo file size for low-bandwidth cellular upload conditions?
- Should customers receive automated SMS tracking links, or are they expected to access links via email?
- How should the system handle a driver attempting to complete a stop out of sequence order?
Half of this already exists
Fieldline
The field half of this is a solved problem: routes assigned, work captured with no signal and synced later, and an alert when nobody shows up.
It is one of our pre-built products: the code is handed over to you, adapted to your own wording and rules, and the rest of the specification above is built on top of it rather than from scratch.
Your product, not this one
Get this written for what you are actually building.
Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.
Next step
Find out if your idea fits in 10 working days.
Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.