Fleet dispatch app architecture: the decisions that matter

Situation: Optimisation is a product by itself; most operators first need visibility and accountable dispatch.

Choice: Phase 1 gives dispatchers a board, capacity checks and ETA estimates; a VRP solver arrives in phase 2 on the same route tables.

• Rejected: Ship a solver first: large effort and hard to trust.
• Rejected: Third-party routing SaaS only: ongoing cost and data egress.
• Consequence: Dispatchers carry the planning workload at first.
• Consequence: Route tables are designed so a solver only writes assignments.

Situation: Drivers lose signal in depots and rural areas; lost or duplicated events create disputes.

Choice: The driver app queues events locally with client event ids; the server accepts batches and dedupes by (stop, client id).

• Rejected: Online only: fails in the field.
• Rejected: Server-generated ids: duplicates on retry.
• Consequence: Clients persist queues across restarts.
• Consequence: Out-of-order events are ordered by occurred_at.

Situation: Raw location data is large and privacy-sensitive; disputes need only coarse tracks.

Choice: Partition pings by day, drop raw rows after 30-90 days, keep a downsampled track per route for disputes.

• Rejected: Keep everything: cost and privacy exposure.
• Rejected: Keep nothing: cannot resolve delivery disputes.
• Consequence: A downsampling job is required before drop.
• Consequence: Retention is a customer-visible setting.

Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.

• customer_accounts: (org_id, name) — customer lookup.
• shipments: unique (org_id, customer_account_id, reference) — customer reference unique so imports are idempotent.
• stops: (shipment_id, seq) — stops of a shipment in order.
• routes: unique (driver_id, route_date, depot_id) — one route per driver per day per depot.
• route_stops: unique (route_id, seq) — order within a route.
• stop_events: unique (stop_id, client_event_id) — offline replay cannot duplicate an event.
• location_pings: (vehicle_id, recorded_at DESC) — recent track for a vehicle.
• vehicles: unique (org_id, plate) — plate unique per operator.

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 is the most important architecture decision for a fleet dispatch app?

Manual sequencing with computed ETAs before an optimiser. Phase 1 gives dispatchers a board, capacity checks and ETA estimates; a VRP solver arrives in phase 2 on the same route tables.

Do I have to make these decisions myself?

No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.

What do the alternatives cost me?

For example, for "Offline-first driver events with client ids": Online only: fails in the field. Server-generated ids: duplicates on retry.

• How to build a fleet dispatch app
• 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