Orus Studio
Logistics & Distribution

Finding out which trips actually made money

A transport contractor running 140 vehicles across west India

An operator with healthy revenue and unpredictable profit, because fuel, driver advances, tolls and detention never reached the trip they belonged to.

Client
A transport contractor running 140 vehicles across west India
Industry
Logistics & Distribution
Duration
11 weeks
Team
3 engineers, 1 designer
Year
2025

The situation

Trip revenue was tracked accurately; trip cost was not. Fuel bills, driver advances, tolls and maintenance arrived days or weeks later and were booked against the month, not the trip.

Management could see monthly profit but could not tell which routes or vehicles were losing money.

Proof of delivery was a signed paper challan that frequently went missing, causing payment disputes with consignors.

E-way bills were generated manually on the NIC portal and occasionally expired mid-transit.

What we did

01

Cost attribution at the point of spend

The driver app records fuel, toll and advance against the active trip at the moment it happens, with a photo of the receipt. Nothing has to be reconciled later because nothing arrives unattached. This was more a behaviour-change problem than a software problem, and the app was designed around a driver using it one-handed at a fuel pump.

02

Digital proof of delivery

Consignee signature, photograph and GPS timestamp captured on the driver's phone, synced when signal returns. Payment disputes that previously took weeks of paper-chasing now resolve by opening the trip record.

03

E-way bill integration with expiry alerts

Direct NIC portal integration for generation and Part-B updates, plus alerts before an e-way bill expires. The alert matters more than the generation — an expired e-way bill in transit is a detention risk that costs far more than the paperwork.

04

Profitability as the primary screen

The main management view is margin per trip, per vehicle and per route, not a list of trips. That framing is what made the system get used by the owner rather than only by operations staff.

The parts that were actually hard

Problem

Drivers had low-end Android phones, intermittent connectivity, and limited literacy in English.

How we handled it

The app is offline-first, uses icons and Hindi labels, and keeps each action to a single screen. We cut the original feature set by roughly half after watching drivers use the first build at a loading point.

Problem

Fuel receipts were photographed at poor angles in bad light, defeating automatic amount extraction.

How we handled it

We stopped trying to make OCR fully automatic. The driver types the amount, the photo is retained as evidence, and the back office verifies against the photo. Reliable and boring beat clever and wrong.

What shipped

  • Trip planning, assignment and consignment tracking
  • Offline-first Android driver app with proof-of-delivery capture
  • Fuel, toll, advance and maintenance cost attribution per trip
  • NIC e-way bill generation, Part-B updates and expiry alerting
  • Per-trip, per-vehicle and per-route profitability reporting

Outcomes

  • Management gained per-route margin visibility for the first time, and discontinued two regular routes found to be running at a loss
  • Payment disputes with consignors dropped sharply once proof of delivery became retrievable in seconds
  • No e-way bill expiries in transit reported since the alerting went live

Outcomes are described qualitatively where no clean measured baseline existed before the work started.

Built with

Next.jsPostgreSQLReact NativeRedisDocker

Have a problem shaped like this one?

Tell us what you are dealing with. We will come back with a scoped estimate and an honest view on whether we are the right fit.

Explore