How to build a fleet dispatch app with AI

These are the parts a fleet dispatch app needs before it is useful. Each one is something the plan covers.

• Operators, depots and customers: Support carriers that serve many shipper customers, each seeing only their own shipments.
• Dispatcher, driver and customer roles: Dispatchers see all, drivers see their own jobs, customers see their shipments.
• Shipments and stops: Model what is moved, from where to where, with time windows and handling needs.
• Dispatch and assignment: Assign stops to driver-vehicle pairs and sequence them against capacity and hours.
• Driver status events and proof of delivery: Capture arrival, completion, exceptions, signature and photo evidence even offline.
• Location tracking with privacy limits: Show where vehicles are now and where they were, without keeping location data forever.
• Vehicle maintenance and compliance: Keep vehicles roadworthy and documents valid.
• Operations audit trail: Show who reassigned, edited or overrode a delivery outcome.

• Live board updates: Dispatch and customer tracking pages update without refresh.
• Customer and driver notifications: Tell customers the ETA and tell drivers about changes.
• Carrier and customer webhooks: Push status changes to customer systems and take carrier updates.
• Order import: Load shipments from CSV/Excel or an API.

Each table below becomes part of the Postgres database that belongs to your app.

• customer_accounts: shipper customers of an operator; webhook secret is stored as a secret reference, not here.
• shipments: status: created|planned|in_transit|delivered|failed|returned|cancelled; the tracking token is random and stored hashed.
• stops: coordinates stored as integer microdegrees; recipient address and contact are encrypted; status: pending|assigned|arrived|completed|failed|skipped.
• routes: assignment checks run in the same transaction as the write: capacity, licence class, hours of service, vehicle document validity.
• route_stops: re-sequencing swaps seq values inside one transaction with deferrable uniqueness.
• stop_events: insert only; kind: arrived|completed|failed|rescheduled|photo|signature|scan; failure reasons come from a controlled list.
• location_pings: high volume insert only; raw rows pruned after the retention window; driver tracking only while on shift.
• vehicles: status: available|in_service|maintenance|retired; last position is an upsert updated from pings.
• vehicle_documents: kind: registration|insurance|inspection|permit; an expired mandatory document blocks assignment.

• No autonomous route optimisation or load planning in phase 1.
• No certified tachograph, ELD or safety functions.
• No tracking of drivers outside shift hours.
• No public exposure of driver identity, phone or exact position away from the delivery area.
• No payments for freight in phase 1 (see accounting-erp).
• Route optimisation: plan for it, build it later.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

What does a fleet dispatch app need first?

Operators, depots and customers, dispatcher, driver and customer roles, shipments and stops, dispatch and assignment, driver status events and proof of delivery and location tracking with privacy limits. The plan for a fleet dispatch app covers all of these before it generates code.

What should I leave out of the first version of a fleet dispatch app?

No autonomous route optimisation or load planning in phase 1. No certified tachograph, ELD or safety functions. No tracking of drivers outside shift hours.

Which products define the fleet dispatch app category?

Well-known examples include Onfleet, Samsara, Route4Me, Routific and ShipBob. Use them to decide which features your users expect, then describe your own version.

• Fleet dispatch app architecture
• Example prompt for a fleet dispatch app
• Fleet dispatch app security checklist
• Fleet dispatch app scaling checklist
• Often combined: inventory system
• Often combined: booking system
• All app types