Replacing a Legacy Freight System in Production

Quick India Logistics Pvt Ltd moves freight across India. The business was running on a legacy platform called Logistics Cube. Grabodo built the system that replaced it - a Next.js 14 application deployed on AWS, with Postgres on RDS, file storage on S3 and hosting on Amplify.

The Background

Legacy operational software is difficult to leave. It holds years of process knowledge, and the people using it have built their working day around its quirks. A replacement that covers eighty per cent of the job is not eighty per cent useful - it is unusable, because the missing fifth is still a daily task.

The Challenge

The freight domain does not simplify. A consignment is a docket, dockets are grouped into manifests, manifests move between hubs, runsheets take them out for delivery, and every one of those has its own printing, its own pending and incoming states, and its own exception handling. All of it had to be rebuilt faithfully before anything could be improved.

Statutory e-way bill handling sat on top of that, and the whole system had to work for a branch network with role-based access rather than a single office.

The Solution

The build follows the operation rather than a generic CRM shape. Booking covers docket creation, delivery information, docket issues and printing including barcodes. Manifests handle forwarding, hub dispatch, incoming, pending departure and pending dispatch, each with its own view and print output. Runsheets cover hub dispatch, incoming, pending delivery and bulk printing.

Underneath sits properly modelled master data - branches, locations, routes, vehicles, vendors, commodities, charges, assets and bill-to parties - so the operational screens read from one source rather than repeating themselves. An employee management module handles users, departments, designations, permissions and credentials, e-way bills get a dedicated dashboard, and a companion Expo mobile app extends the platform into the field.