Client background
EMAYYAM INFOTECH is an IT services company based in Coimbatore, India, operating across publishing, accessibility services, recruitment, and data management. As part of their operations, the company manages a fleet of vehicles used for field operations, client visits, and logistics support across their service lines. Jey C., the Head of Business Development, approached Squash Apps with a specific operational problem: fuel costs were running significantly above what the fleet size and operational requirements should justify, but the company lacked the data infrastructure to understand why.
The company already used an ERP system to manage core business operations — but the ERP was not integrated with any fleet management capability, and fuel usage was being tracked through a combination of paper logs and manual data entry. This manual tracking was inconsistent across different departments and vehicles, creating an accurate-looking dataset that was in practice quite unreliable.
EMAYYAM also wanted to build HR and admin management functionality as a secondary workstream, leveraging Squash Apps' understanding of their systems and workflow requirements developed during the fuel management engagement.
The challenge
The fuel management problem at EMAYYAM had several dimensions. The most basic was simply visibility: without reliable, real-time data on fuel consumption per vehicle, route, or driver, there was no way to identify where the overuse was occurring. Management knew costs were too high but had no data to support targeted interventions. This is a common problem across asset-intensive businesses — the operational costs are visible in the accounts, but the root causes are invisible without a dedicated tracking layer.
A secondary problem was procurement controls. Fuel could be purchased using company fuel cards at any participating station, and the reconciliation process between fuel card statements, paper logs, and actual vehicle usage was manual and time-consuming. Without automated reconciliation, small discrepancies — potential indicators of misuse or card fraud — were difficult to detect. In a fleet of dozens of vehicles with multiple drivers, even minor per-vehicle fuel leakage accumulates quickly into a significant annual cost overrun.
Vehicle maintenance scheduling was linked to the fuel management problem: vehicles running inefficiently (due to poor tyre pressure, engine issues, or sub-optimal routes) consume more fuel, and those same mechanical issues tend to cause breakdowns if not caught and addressed. Without data linking fuel consumption patterns to individual vehicles, preventive maintenance scheduling was purely calendar-based rather than condition-based — missing the early warning signals that data-driven maintenance programmes are specifically designed to catch.
The integration with the existing ERP was a specific requirement from the client: the fuel management data needed to flow into the existing accounting and cost reporting structure rather than creating a separate data silo. This required understanding the ERP's data model and API capabilities, which were specific to the vendor the client used. A standalone fuel tracking tool that required parallel data entry into both systems would not have solved the operational problem — it would have added to it.
How we engaged
The engagement was completed in approximately six weeks — an unusually short timeline that reflects both the focused scope of the MVP and the closeness of the collaboration between Srijith's team and EMAYYAM's technical team. Jey C. specifically noted in his review the quality of the working relationship: "Meticulous with their tasks, they were working closely with our tech team at every phase."
The discovery phase involved in-person meetings with the operations team to understand how fuel purchases were currently being made, how vehicles were allocated to tasks, and how the existing ERP handled cost centre accounting. This on-the-ground understanding was essential for designing an integration that would actually fit into the existing workflow rather than requiring the operations team to change how they worked.
Squash Apps managed the project with proactive communication throughout: regular status updates, detailed explanations of technical choices and their trade-offs, and immediate responsiveness to queries from the client's team. This communication style — which Jey C. highlighted specifically as a differentiator — was particularly important in a short-timeline engagement where slow information flow could have derailed delivery.
What we built
The fuel management system was delivered as a web application with four primary modules. The vehicle and driver registry established the foundational data: each vehicle in the fleet was registered with its specification, fuel type, and expected consumption benchmarks; each driver was associated with their typically assigned vehicles.
The fuel transaction log replaced the paper-based system with a structured digital record. Transactions were entered via the web app (or, for supported fuel card providers, imported automatically via API), linked to the specific vehicle and driver, and validated against the vehicle's expected consumption rate. Transactions that fell outside expected parameters — either significantly above or below the vehicle's typical consumption for a given distance — were flagged automatically for review.
The analytics dashboard gave management the visibility that had previously been absent. Fuel cost per vehicle, per route category, and per driver was visible in real time. Month-on-month trend analysis made it straightforward to see whether consumption was improving or deteriorating following interventions. The dashboard's most operationally useful feature was the outlier detection: a visual display of vehicles whose consumption was consistently above fleet average, with drill-down capability to see the specific transactions driving the deviation.
The ERP integration was implemented as a scheduled batch export: at the end of each day, the fuel management system generated a structured transaction file in the format required by the client's ERP, which was imported automatically into the ERP's cost accounting module. This eliminated the manual data re-entry that had previously been required and ensured that fuel cost data was available in the ERP with a maximum one-day lag.
The HR and admin management application was delivered as a second workstream: a structured system for employee record management, leave tracking, and administrative workflow management, again integrated with the ERP for payroll-relevant data flows.
Technical approach
The fuel management system was built as a React frontend with a Node.js/Express backend, backed by a PostgreSQL database. The technology choices reflected the requirements: React for a responsive, maintainable web interface accessible from any browser; Node.js for a lightweight, performant API layer; and PostgreSQL for reliable relational data storage with strong transactional guarantees. The ERP integration used the client's ERP vendor's documented file-based import interface — a batch processing approach that was appropriate for the daily reconciliation cadence required and that didn't require real-time API access to the ERP system.
The consumption anomaly detection algorithm compared each transaction against a rolling baseline for that vehicle, calculated as the median consumption per kilometre over the preceding 30 days. Transactions more than 1.5 standard deviations above or below the baseline were flagged. This statistical approach was deliberately simple — chosen to avoid false positives that would erode trust in the system — but proved sensitive enough to surface the most significant inefficiencies. The team also implemented a driver attribution model: because vehicles were often driven by multiple drivers, the anomaly detection cross-referenced driver assignment data to distinguish vehicle-level issues (consistent deviation regardless of driver) from driver behaviour issues (deviation concentrated in specific driver-vehicle combinations).
The mobile-responsive design ensured that field staff responsible for entering fuel transactions could do so on their phones immediately after a fuel stop rather than returning to an office terminal. Input validation on the transaction entry form caught common errors (wrong unit, missing odometer reading) at the point of entry rather than during batch processing. Progressive Web App techniques were applied to improve performance on mobile networks common in Coimbatore's mixed urban and suburban operational territory — the app loaded quickly on 3G connections and cached core reference data (vehicle list, driver list, fuel station list) locally.
Results
The operational impact was significant and measurable. Within the first months of deployment, EMAYYAM identified several specific patterns driving overconsumption: certain vehicles were consistently consuming more than their benchmarks, pointing to maintenance issues; certain routes were being driven with sub-optimal fuel efficiency; and a small number of fuel card transactions were flagged as inconsistent with the associated vehicle's recorded usage. Each of these findings would have been invisible without the data infrastructure the system provided — and each represented a different category of intervention that management could now pursue with confidence.
Fuel costs fell by 35% compared to the pre-deployment baseline — a result that substantially exceeded EMAYYAM's own estimates of what was achievable. This improvement reflected both the direct interventions enabled by the new visibility (addressing the specific vehicles and behaviours driving overconsumption) and the secondary effect of simply having a tracking system in place: awareness of monitoring changes behaviour, and the fuel card reconciliation process alone removed a category of leakage that had been difficult to detect under the manual system.
The maintenance cost reduction of 15% followed from the more systematic maintenance scheduling that the data enabled: instead of scheduling service purely by calendar interval, the team could now schedule proactively for vehicles showing consumption patterns associated with developing mechanical issues. This condition-based maintenance approach — a well-established best practice in fleet management that had previously been impractical without data infrastructure — reduced both breakdown incidents and the higher repair costs associated with reactive versus preventive maintenance.
Jey C.'s assessment was unequivocal: "We feel it is a huge success for us and the credit goes to Srijith and Squash Apps team." The return on investment from fuel and maintenance savings alone significantly exceeded the development cost within the first year of operation. As a custom fleet management software development engagement, this project demonstrates the return available to asset-intensive businesses when operational data visibility is treated as a strategic investment rather than a cost.