Courier delivery service
Orders are assembled into routes, the courier runs their day from a phone, and the customer sees the status instead of calling to ask where the parcel is.
- Buildfrom $3,550
- Timeline6–10 weeks
- Supportfrom $420/mo
Who this suits: Delivery done in-house, where routes are assembled in a spreadsheet, couriers are steered by phone, and the customer gets a half-day window.
What is in the first version
- routes for the day
- courier app
- proof of handover
- customer status page
The figures above are the package this sits on: MVP or full product. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
Orders become routes
The route is built from addresses, windows and weight, and the dispatcher edits the sequence by hand.
- 02
The courier works from a phone
The next address, the amount to collect, and the stop closed on the spot, signal or no signal.
- 03
The customer sees what dispatch sees
The order page shows the courier and how many stops are ahead, and a narrowed window arrives as a message.
What decides whether this works or annoys people
The second attempt costs more
A failed delivery costs a courier day, so the customer confirms before the run and reschedules from the order page.
Cash in the courier’s hands
The amount is recorded at handover, and a per-courier reconciliation for the shift is in the first version.
A free-text address breaks the route
The address is normalised when the order is placed, and doubtful ones reach the dispatcher, not a courier in a courtyard.
What to measure once it is live
- delivered on the first attempt
- stops per courier per shift
- deliveries inside the promised window
- calls asking where the order is
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- Courier appFlutterKotlinSwift
- Orders, routes and serverNode.jsPythonPostgreSQLPrismaRedis
- Dispatcher screen and customer pageTypeScriptReactNext.jsTelegram Bot APIDockerGrafana
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- maps, route building and geocoding
- SMS to the customer about the window
- app store accounts and mobile data
- the card terminal and the bank’s percentage
Asked before the first call
- Why not use an outside delivery service?
- If the volume is small and timing is not what makes you different, use one. Your own delivery pays off where the window, the packaging or the door conversation has to be yours.
- Will the routes be built automatically?
- The sequence is proposed by a calculation and the dispatcher has the last word. We do not ship a version where a route cannot be edited by hand.
- Will the couriers cope with an app?
- The courier screen is one stop at a time and three buttons: arrived, handed over, did not work out. Anything outside that set goes to the dispatcher by phone.