FleetSetu

The company had a transport management system. It was built for fleet hired from the market, where the crucial data is rates and vendors. The company's own vehicles were an afterthought in it. So the own-fleet team did what every team does with a system that was not built for them: they used it as a formality.

• The real work lived in spreadsheets saved locally. The TMS was updated afterwards, for monitoring and a few automations.
• Almost every report came from one file, the Daily Shipment Report. Each was built by hand. Some took an hour and a half to two hours a day.
• Tracking was reactive by design. Today's statuses were discussed tomorrow.

The tracking sheet itself was the hidden cost.

The first version ran on Google Apps Script with Google Sheets as the database. Free to host, quick to deploy, a database the team already understood, email automation built in, sign-in restricted to the company domain with no setup. It also had a ceiling: however much you optimise the script and the sheet, every interaction carries a 30 to 40 second lag, and retrieval slows as the data grows.

• Report-making, automated~50 h / month

  An hour and a half to two hours a day of hand-built reports, now generated by the app and emailed on their own.

• Time per update30–40 s → under 1 s

  The move to Firebase. Shown live in chapter three.

• Consolidated viewson demand

  Any cross-team view the team needs later is a query, not an afternoon in a spreadsheet.

Because the tracking data was now live, the planning team could see which vehicles needed a plan as it happened, rather than the next morning. And since planning creates the trips that tracking then follows, I built the trip module and the tracking module together.

• 01 Tracking One status model, not three vocabularies. A small set of primary statuses with optional sub-tags. GPS from the TMS arrives as a confirmation flag, never as a status change: position is the machine's job, status is a person's accountability.
• 02 Trips Per-vehicle, per-day profitability. Every expense tracked against the trip. Google Maps distance is shown as a reference kilometre when a trip is created, so entered kilometres stay close to real ones and extra kilometres stop leaking expenses.
• 03 Round trips The view leadership wanted. Which lanes make money. A round trip closes itself when the vehicle reaches its hub city, using the Maps API.
• 04 GPS on demand Once a day, plus a toggle. The team could not keep up with live pings, so location is fetched once a day, with a toggle to fetch any vehicle when someone needs it.
• 05 Reports Generated, then emailed. The reports the team used to build by hand, including the client's daily snapshot, produced from the data and sent on their own.
• 06 Feedback to the developer One button copies the error. If a user hits an error, one button copies it into a feedback note. I pass that straight to Claude Code, which is how fixes shipped in hours rather than days.

Then the rebuild: the same product on Firebase Hosting, Auth and Firestore, with role and fleet access enforced in database rules and a deploy pipeline through GitHub Actions because the client laptop allows nothing to be installed. The whole fleet was on it within a week.

Entering tracking and trip details in the app took the same time as filling the local spreadsheet, and the trip details were supposed to be entered by a different team anyway.

Take feedback from the doers, but do not rely on it blindly. Every team resists change, and the way work is reviewed has to change along with the tool. If the review still accepts the offline spreadsheet, the offline spreadsheet wins.