Six roles that each moved closer to the vehicle

Mandate

Replace paper crew records and an ageing booking engine without interrupting nightly departures, and make fleet and parcel data reliable enough for pay, compliance and board decisions.

Outcomes

• Location gaps reduced from 17 to 2.6 per cent of trip-hours across the fleet
• Crew handheld deployed on all 418 coaches; seat conflicts reduced from about 310 to 18 a month
• Parcel counter platform live in six months for ₹2.1 crore; document detentions down from 23 to three a year
• 41,600 seats sold on the busiest day after Diwali 2025 with no booking outage

Decisions in context

This is the first role in which I answer for the whole technology function rather than one product. Malvaneer had grown through its sleeper services and family relationships, and its systems reflected that history: a twelve-year-old booking engine, paper crew records and tracking units bought by three different teams. I report to Siddhant Rathvekar, the managing director, and lead five managers. Since the investor joined in 2022 I have presented quarterly to the board and reported to its audit and risk committee on availability, cyber exposure and vendor dependence. I do not set fares, plan routes or decide driver fitness. The three cases on this site come from this role, and each altered a rule that operations or revenue colleagues had relied upon. I made sure those colleagues saw the evidence before they were asked to accept the change.

Reason for the move

Current role; preparing for a first independent directorship alongside it, subject to the managing director's consent.

Mandate

Build the load-matching platform, driver application and proof-of-delivery capture, and turn a pilot telematics product into a paid subscription.

Outcomes

• Proof-of-delivery capture adopted by 7,200 registered truck owners and drivers
• Telematics subscription grown to 3,100 trucks among owners with fewer than ten vehicles
• Average time from delivery to proof received cut from six days to under one

Decisions in context

Kheralink taught me what small fleet owners will tolerate from software. Many of them ran three or four trucks, shared one phone among several drivers and judged an application by whether it helped them get paid sooner. I reported to Parth Ambavade, the co-founder, and built the team from eleven engineers to 46. Proof of delivery mattered most: a photographed, time-stamped receipt shortened payment cycles and reduced disputes with shippers. Telematics was harder. A product decision made before my arrival smoothed device gaps on the customer's map, and I reversed it after a shipper relied on a smoothed route in a damage claim. Presenting to a board with investor nominees was new to me. I learnt to bring the reliability figures I would rather not show, together with what we were doing about them.

Reason for the move

The freight business was sold to a larger logistics group in early 2021; I chose to lead technology at an asset-owning operator rather than move with it.

Mandate

Replace paper delivery runsheets with a handheld application that works through a full shift without a connection.

Outcomes

• Handheld application rolled out to 3,800 delivery staff across 410 branches
• Cash-on-delivery reconciliation differences reduced by about half within a year
• Offline conflict rules agreed with branch managers and published in local languages

Decisions in context

The scale at Durvanta was unlike anything I had handled. Thousands of couriers would use our application every day, and most had never used a smartphone for work. I reported to the head of information technology and led eighteen engineers and testers. We designed for a full shift without a connection, which meant deciding in advance how conflicting changes would be settled when a courier and a branch clerk edited the same consignment. I insisted those rules be agreed with branch managers and printed in the languages couriers actually read. Cash on delivery was the hardest workflow, because an unrecorded collection could look like theft. Recording every collection on the device roughly halved reconciliation differences. I also learnt to budget for devices that are dropped, lost and charged in vehicles, which is now part of every crew technology plan I write.

Reason for the move

Joined a freight-matching platform to build a product used by independent fleet owners rather than employees.

Mandate

Build and support depot and cash reconciliation systems for public and private bus operators.

Outcomes

• Delivered depot back-office systems for eleven bus operators
• Redesigned a reconciliation report to show how each total was derived
• Reduced month-end support tickets on one large deployment by around 40 per cent

Decisions in context

Ashvetra moved me from devices to databases. I joined as a senior software engineer and became technical lead of a nine-person team in 2010. Our clients were bus operators, some public and some private, who needed depot systems to reconcile ticket sales, cash deposits and fuel issues. I spent more time in depots than in our Pune office, because the people using the system were cashiers and depot managers rather than head-office analysts. I watched a reconciliation report become evidence in a dispute between a conductor and a cashier, and realised that a total without its derivation could unfairly accuse someone. We redesigned the report to show every component of each figure. Services work also showed me the limits of a contractor: we could recommend changes to an operator's process, but the operator decided. I wanted to sit on the deciding side.

Reason for the move

Moved to an operating company to own a product used every day by field staff.

Mandate

Write and maintain tracking-unit firmware, particularly its behaviour without mobile coverage.

Outcomes

• Designed position buffering for up to 72 hours without a signal
• Introduced a confidence flag on positions taken with weak satellite reception
• Reduced field returns on one model by about a third through power-handling fixes

Decisions in context

At Telvarika I wrote firmware for tracking units sold mainly to truck owners. The work sat close to the hardware: power handling, satellite reception, memory limits and what to transmit first after an hour without coverage. I worked in a six-person firmware group under the head of engineering and had no direct reports. The most useful thing I did was add a flag to positions recorded with weak reception, so that receiving software could treat them with caution. A sales colleague once asked us to hide gaps on customers' maps because they made the product look weak. I declined, and the head of engineering supported me. I also spent days with installers, since a badly installed unit produced faults that no firmware could correct. I left because I wanted to understand how the systems receiving our data actually used it.

Reason for the move

Moved into software services to work on the systems that consume device data.

Mandate

Keep ticket machines working in service and teach conductors and owners to use them.

Outcomes

• Supported about 600 machines across 40 bus operators
• Documented recurring battery and printer failures for the design team
• Ran conductor training sessions at bus stands across western Madhya Pradesh

Decisions in context

My first employer made the ticket machines conductors carried on private buses. I joined as a graduate engineer trainee and became a field service engineer within a year, reporting to the service manager. Most of my days were spent at bus stands, opening machines that had failed in service and explaining to owners why a day's figures were incomplete. I learnt that most failures were ordinary: a battery charged from an unreliable coach supply, a paper roll loaded badly, a machine dropped in a rush. I wrote those patterns up for the design team, which changed the battery holder on the next model. I also trained conductors, many of whom distrusted a machine that counted their sales. Their questions were fair. That experience made me want to write the software inside the device rather than keep repairing what it failed to record.

Reason for the move

Moved to Pune to write firmware rather than repair the devices that ran it.