Fleet Management SaaS for a 14-Hub 3PL — 22% Cost-per-Delivery Reduction, Zero Lost Shipments

The client & the problem

The 3PL had grown from one hub to 14 in three years — and the cost structure had grown faster than the revenue. Each hub had its own dispatcher, its own Excel template, its own informal rules, and its own version of the truth. Shipment status was a phone-call away. Billing reconciliation took three weeks per cycle. The CFO wanted out.

• Hub fragmentation: Each hub owned its operational stack. Reconciling them at month-end was a person-week of work that often missed shipments entirely.
• Vehicle utilisation blind: Vehicles were idling at 38% utilisation and management had no view of why. Routes were planned by feel.
• Lost shipments: An average of 3-4 shipments per month became 'untraceable' — no proof of pickup, no proof of delivery, no audit trail.
• Billing leakage: 10% of billable shipments were under-billed because the surcharge rules (volumetric, ODA, fuel, GST) were not applied consistently.
• Customer experience: Customers had no live tracking. Every 'where is my parcel?' was a phone call to a hub that didn't know.

The solution

We deployed our productised Courier Management Software (the same platform behind ITD's Trackmate Lite product) with 3PL-specific configuration. The non-negotiable design choice: a single source of truth across all 14 hubs, with hub-level autonomy in workflow but central authority on billing and SLAs.

1. Web admin (React)

Central control tower. Live shipment board (filterable by hub, route, customer, SLA-status), unified manifest builder, hub-onboarding wizard, customer onboarding, pricing ruleset (rate-cards, surcharges, exemptions), payout reconciliation, MIS reports, alerts.

2. Hub-staff app (PWA)

Hub-side ops: pickup scan, sortation, manifest-out, hub-in, hub-out. Bluetooth scanner support for barcode wands. Works offline; syncs when network returns.

3. Driver app (Flutter)

FCM-pushed pickup orders, navigation, OTP delivery, photo proof-of-delivery, in-app earnings. Designed to work on Android Go phones (target rider-grade hardware).

4. Customer tracking page (Next.js)

Public-facing page reachable by AWB or order ID. Live GPS, ETA, delivery photo, support chat. Embeddable on the customer's own site.

5. Backend (Node.js + PostgreSQL)

Single Postgres cluster (the source of truth) with hub-aware tenancy (row-level security). Bull queue for outbound webhooks, integrations with Tally, GSTN, and customer ERPs. Read replicas for the MIS dashboards.

Tech stack & why

We picked the stack for fit, performance under realistic load, and operational simplicity. Here is the breakdown:

One Postgres, row-level multi-tenancy: we considered per-hub databases (simpler isolation) and hub-aware single-tenant (simpler queries). The 14-hub case was small enough to keep one cluster with row-level filters, big enough to need read replicas. The decision saved months of cross-hub reconciliation work.

NestJS + TypeScript: the entity-relationship complexity (shipment → leg → manifest → vehicle → driver → hub → customer → invoice) is high. The DI + module structure makes it manageable; you stop fighting the framework about a year in.

PWA for hub-staff, Flutter for drivers: hub PCs are mostly Windows and dispatchers don't install apps. PWA covers it. Drivers are Android-first, often on entry-level hardware; a Flutter app gives the offline behaviour Android Web doesn't.

The hardest technical problem we solved

Manifest-and-bag math at scale.

Logistics ops is a graph problem. A shipment travels: customer → pickup → originating hub → bag → vehicle → transit hub → bag → vehicle → destination hub → driver → customer. Every transition is a chance to lose visibility.

The hardest part: bag-level reconciliation. Hubs ship in bags; bags contain shipments. If a bag is opened in the wrong hub, or if a shipment goes into the wrong bag, the system has to detect it within minutes, not days.

We modelled the entire journey as a directed graph with state-machine transitions per shipment, per leg, per bag. Every scan is a state transition; every illegal transition (bag-open at wrong hub, shipment-not-in-manifest) raises an alert.

Result: lost shipments dropped from ~3-4/month to zero across 6 months and 300,000+ shipments. The CFO no longer maintains a spreadsheet of 'unaccounted parcels' — there isn't one to maintain.

Go-to-market & ramp

We piloted at the largest hub for 6 weeks. The hub manager was the toughest critic; if it survived him, it would survive the others. Three workflow changes came out of pilot — hub-staff app needed barcode-wand pairing in 2 taps not 5; manifest printing needed a per-route summary; payout reconciliation needed a daily auto-run.

Cross-hub rollout was driven by a hub-onboarding wizard (rate cards, hub geometry, staff users, integrations). Hubs 2-14 onboarded at a rate of one per 7-10 days. By month four, all 14 hubs were on one platform.

Results

What we would do differently

Push customers to the public tracking page in week one, not month two. Customer-side trust grew slower than it could have because we let the WhatsApp-update habit linger; the moment we made the public page the canonical answer to 'where's my parcel?', support tickets halved overnight.