SKIP TO CONTENT
A/L
SYS_003BUILDING

Logixmap

Fleet, Tour & Driver Operations

Assign tours to drivers, follow them on the ground, and close each trip with proof and settled expenses.

TYPE
FLEET SYSTEM
STATUS
BUILDING
YEAR
2026
ROLE
System design, full-stack implementation
PLATFORM
Flutter (Android driver app + web console), Node.js API
STACK
Flutter · Node.js · MySQL · REST · Geolocation
01

PROBLEM

Transport operations are coordinated by phone call and remembered by nobody. A manager assigns a tour verbally, the driver spends cash on fuel, tolls and loading, keeps the slips in the cabin, and settles up days later from a crumpled bundle.

The office cannot answer what a specific trip cost, which driver is where, or whether a delivery was actually completed — because the record of the work and the record of the money live in different heads.

02

SYSTEM

Logixmap models a tour as the unit of work. A tour is planned, assigned to a driver and a vehicle, executed with stage and location updates, expensed against a budget, evidenced with documents, and only then closed.

Roles are hierarchical: an owner sees the fleet, a manager sees their drivers, a driver sees their own tours and nothing else. The same API enforces that scope, so the mobile app cannot request data outside it.

Expenses and proof are captured where they happen — on the driver phone, at the moment of spending — which is the only point at which the information actually exists.

03

CORE FLOW

How the operation moves through the system.

ARCH_01 / TOUR LIFECYCLE
  1. Route, stops, vehicle, expected cost and time window
  2. Assignment with availability and duty-hour checks
  3. Fuel, toll, loading and advance recorded against the tour
  4. Photo of slip, delivery note or signature, stamped with time and location
  5. Tour closed, driver advance settled, cost posted to accounts
SELECT OR HOVER A NODE FOR DETAIL

A tour moves through five stages: tour planning, driver assignment, expense capture, proof of delivery, and completion with settlement.

ARCH_02 / ROLE HIERARCHY AND DATA SCOPE
MANAGER
  • Sees only own assigned tours, own expenses, own documents
  • Location is reported only while a tour is active
  • Cannot edit a closed tour or a settled expense
SELECT OR HOVER A NODE FOR DETAIL

A manager node with three driver nodes beneath it; each driver can only see their own tours and expenses.

04

KEY MODULES

M01Tour planning
Route with stops, assigned vehicle, expected cost and time window.
M02Driver scheduling
Availability, assignment, duty hours and reassignment history.
M03Live position
Location reported during active tours only, at a battery-aware interval.
M04Trip expenses
Category-wise entry against a tour, with advance and balance tracking.
M05Document workflow
Proof capture, review, approve or reject with a stated reason.
M06Vehicle master
Documents, service due dates and per-vehicle running cost.
M07Settlement
Driver advance against spend, closed out per tour and posted to accounts.
05

ARCHITECTURE

Driver client
Flutter Android app built for one hand, poor light and worse connectivity.
Console
Flutter Web operations console for planning, approval and reporting.
API
Node.js REST with role-scoped queries; hierarchy is resolved server-side.
Data
MySQL; tours, expenses and documents become immutable once settled.
Media
Proof images compressed on device before upload, then held as document records.
Accounting link
Closed tours post trip cost and driver settlement into the shared accounting engine.
06

ENGINEERING

The parts that were not obvious, and what the system does about them.

  1. 01 / 04

    Location that does not eat the battery

    A driver app that drains a phone by noon gets uninstalled. Reporting is tied to tour state — an active tour reports at a coarse interval with distance filtering, and an idle app reports nothing at all.

  2. 02 / 04

    Expense entry in a moving vehicle

    The capture screen is designed for a person standing at a fuel pump: large targets, category first, amount second, photo optional but prompted. Anything more elaborate simply does not get filled in.

  3. 03 / 04

    Trusting the proof

    A photo on its own proves nothing. Proof records carry capture time and coordinates from the device, and the review step separates submitted from accepted, so a rejected slip has a reason attached to it.

  4. 04 / 04

    Hierarchy as a query, not a filter

    Role scope is applied when building the query rather than by filtering results afterwards. That is the difference between a permission model and a UI that merely hides rows.

07

SCREENS

  1. SCREEN_01Console — tour board by driver
  2. SCREEN_02Driver app — active tour and stages
  3. SCREEN_03Driver app — expense capture
  4. SCREEN_04Console — document review queue
08

RESULT

Every trip has a record: who drove it, where it went, what it cost and what evidence exists that it was completed.

Driver settlement becomes a screen instead of an argument, and per-vehicle and per-route cost stops being guesswork.