Saai Rathinasamy
All work Full-Stack · AI · Logistics · Side project

Zapdos Fleet Track — designing AND building a full-stack logistics platform

On the side, I designed and built a production logistics platform that runs a real pharmaceutical-distribution company's entire delivery lifecycle — from photographed paper invoices, through AI route creation and live driver tracking, to proof-of-delivery, invoicing, and client quotes. Three portals, one system, shipped and in daily use.

Role

Sole product designer AND full-stack engineer

Client

Pharmaceutical distributor, Tiruppur, India (side project)

Platforms

Dispatcher web · driver app (mobile) · customer portal

Stack

React · TypeScript · Tailwind · Express · PostgreSQL · WebSocket · Google Routes v2 · GPT-vision · jsPDF

Live
in daily production use
3 portals
dispatcher · driver · customer
Paper → Digital
trip sheets, routing, invoicing
Solo build
designed & engineered
Zapdos live fleet dashboard with real-time driver positions
The dispatcher's live fleet dashboard — real-time driver positions over WebSocket. (Sample data.)
The challenge

An entire operation run on paper and memory.

They needed one system covering the whole lifecycle that fit three very different users — without forcing anyone to change how the business actually worked.

A growing pharmaceutical distributor was running its entire delivery operation on paper trip sheets, phone calls, and a dispatcher's memory. Routes were planned by hand. Drivers had no live guidance and no enforced order. Proof-of-delivery was a photo on someone's phone, and invoicing was manual, slow, and easy to get wrong — especially when multiple drivers shared a truck or multiple customers sat inside the same physical store.

Routes by hand

Planned manually from memory — no optimization, no way to balance load across drivers.

Drivers flying blind

No live guidance and no enforced delivery order once a driver left the depot.

Proof-of-delivery lost

POD was a photo on someone's phone — nothing traceable, nothing tied to billing.

Manual, error-prone billing

Slow to produce and easy to get wrong — worse with shared trucks and same-store customers.

Three very different users

A dispatcher at a desk, a driver on a phone mid-route, and a customer checking status.

Don't break the business

It had to fit the messy reality — including intake from photographed paper invoices.

My role & approach

The system gets smarter by respecting the operators.

I started from the paper — the company's existing trip sheets and invoices, and the informal rules the dispatcher carried in their head.

The reality I had to fit

  • Photographed paper invoices
  • Drivers' hard-won routing intuition
  • Three distinct user contexts
  • A live business that couldn't pause

What I owned, end to end

  • Modeled the real delivery lifecycle
  • Designed 3 role-specific interfaces
  • Built the frontend + backend
  • Integrated GPT-vision intake & route optimization
  • Designed the branded PDF suite

Three insights shaped everything:

  • Meet the paper where it is. Clerks still work from photographed paper invoices, so intake had to accept a photo, not force manual entry.
  • Learn the operators, don't fight them. Experienced drivers had hard-won intuition about delivery order; the tool should absorb it, not override it.
  • Three users, three contexts. A dispatcher, a driver mid-route, and a customer need genuinely different interfaces — not one responsive compromise.
Why they trusted it

The hardest call was route optimization. Instead of forcing an algorithm's order onto experienced drivers, I built a learning layer: Google Routes solves the route for up to 25 stops, but a pairwise store-preference model quietly records how drivers really sequence deliveries and adapts future suggestions. Intake was the second pivotal call — GPT-vision reads photographed invoices, fuzzy-matches stores, and every dispatcher correction makes the next extraction more accurate.

GPT-vision reading a photographed invoice into structured stops
AI intake — GPT-vision reads a photographed invoice, fuzzy-matches stores, and lets the dispatcher review. (Sample data.)
The solution

Three role-specific interfaces, one connected system.

Each user gets an interface built for their context — desk, road, and inbox — over a single shared backend.

Portal 01 · Desktop

Dispatcher — the operations command center

Problem

The dispatcher held the whole operation in their head — routes, drivers, stores, and billing all at once.

Decision

A desktop command center: live fleet dashboard, route planning & optimization, store/customer management, and billing.

Tradeoff

Information density over minimalism — the dispatcher needs everything at a glance, not a wizard.

Outcome

One screen to run the day — planning, tracking, and billing in the same place.

Route operations dashboard
Dispatcher — route operations.
Portal 02 · Mobile

Driver app — built for one hand, mid-route

Problem

A driver mid-route can't fight a dense UI — they need the next stop, navigation, and a fast way to prove delivery.

Decision

A mobile-first flow: today's stops in suggested order, live navigation, and a fast POD flow (multi-photo + geotag + timestamp, e-signature, notes).

Tradeoff

Sequential-delivery enforcement and same-store grouping add rules — worth it for accurate billing and order.

Outcome

Drivers follow it because it respects how they already work — and POD is captured, not lost.

Driver route map on mobile
Driver — route map (mobile).
Portal 03 · Documents

Client-facing — a branded PDF suite

Problem

Route sheets, delivery reports, invoices, and quotes all had to look professional and paginate cleanly.

Decision

A custom jsPDF engine with careful pagination and section-level "keep-together" rules across every document type.

Tradeoff

Building a real layout engine instead of dumping HTML to PDF — the only way to get dependable output.

Outcome

Every client document looks intentional — a small company that reads as a serious one.

Branded quotation PDF
Client-facing — branded PDF suite.
Full route detail view
Dispatcher — route detail & optimization.
Driver dashboard
Driver — today's stops.
Active route card
Driver — active delivery card.
Under the hood

The "designer who ships" proof.

  • Fleet-scale route optimization: Google Routes API v2 TSP solve (≤25 stops) with a geographic-clustering fallback, plus three strategies (traffic-aware, traffic-unaware, driver-learned).
  • Self-improving AI matching: GPT-vision invoice OCR + fuzzy store-matching that learns from dispatcher corrections over time.
  • Route learning from behavior: a pairwise preference model recording real driver sequences on route completion, blended with geographic data for future ordering.
  • Real-time GPS: a WebSocket architecture broadcasting live driver locations to dispatchers, with database persistence.
  • Multi-customer same-stop handling: one unified driver card per physical store, with individual sub-stop records maintained on the backend for accurate billing.
  • Professional PDF engine: custom jsPDF layout logic — section pre-measurement, keep-together rules, dynamic pagination, branded headers across every document.
  • Billing pipeline: auto-generated invoices from delivered stops, per-customer box-rate math, and driver-level filtering for shared vehicles.
Outcome & impact

One connected system, live in daily use.

Live
in production, used daily for pharmaceutical distribution
3 portals
dispatcher, driver, and customer — one connected system
Paper → Digital
replaced paper trip sheets, manual routing, and manual invoicing
End-to-end
intake → routing → proof-of-delivery → billing
  • Replaced paper trip sheets, manual routing, and manual invoicing with one connected system.
  • Put AI where it earns its place — removing drudgery (reading invoices) and augmenting expertise (route learning).
  • Designed and built solo, research to production — the clearest proof of a designer who ships.
Reflection

The clearest proof of how I work now.

I don't just design the flow — I can build it, ship it, and put real AI to work where it removes drudgery or augments human expertise.

Design and build aren't separate.

Owning both let me model the real lifecycle and turn it into working software, not a spec someone else interprets.

Put AI where it earns its place.

Reading invoices removes drudgery; route learning augments expertise. AI as a tool, not a headline.

Automation earns trust by learning.

It earns trust fastest when it learns from the people doing the work, rather than replacing their judgment.