iTRAMS — I Built a Tyre Lifecycle SaaS and Scaled It to 250 Customers
- Jul 8
- 7 min read
Updated: 6 days ago
Case Study · Founder · SaaS ERP · Sustainability · 2020–2022
Role: Founder, TNT CTSx Technologies
Scope: 15-person team · Bootstrapped · DPIIT-certified startup
Stack: AppSheet, Android · iOS · NodeJS · GCP
Domain: Logistics · Manufacturing · Sustainability
Status: Live — 250+ enterprise customers
Period: February 2020 – December 2022
I didn't start iTRAMS because I saw a market opportunity. I started it because I spent time
on the floor of a retreading plant in Odisha (India), and couldn't find a single piece of paper that told the owner how many tyres were in process, which ones had failed inspection, or what his raw material stock looked like. He was running a business worth crores on memory and WhatsApp forwards. The software problem was obvious. What I underestimated — and what this case study is really about — was everything that wasn't a software problem.
Verdict: Smart but fragile at scale.
iTRAMS works exceptionally well in organised, motivated tyre operations with digital-ready staff. It collapses under the weight of India's unorganised trucking sector — where the real problem isn't the software, it's behaviour change at the bottom of the supply chain.
Section 1 — The Problem
77% of India's end-of-life tyres go to landfills, are illegally dumped, or are burned for fuel. Only 7% are recycled. Retreading — the process of replacing a worn tyre's tread on an intact casing using just 26 litres of oil, compared with 80 litres for a new tyre — offers a genuine circular economy solution. It cuts costs by 67%, reduces oil usage by 60%, and eliminates landfill contribution. The technology exists, the economics are compelling, and the market is large. Tyre sales in India are projected to grow from 36,000 crore to 51,000 crore by 2030. The retreading market sits at 10–13% penetration when it should be 70%. So why is retreading so underused?
The retreading industry in India is almost entirely unorganised. Small operators manage 250–300 tyres per month on paper logs, WhatsApp messages, and owner memory. There is no visibility into which tyres are in which stage of the retreading process, no quality tracking, no data on failure modes, no customer communication system, and no analytics. Tyres get mismanaged, retreads fail prematurely, customers lose confidence, and the cycle repeats.
Tyre management on the fleet side is equally broken. A 15-tonne truck runs on 10 tyres and covers 108,000 km annually. Tyre costs represent 8–10% of total trip expenses — the second-highest cost after fuel. Yet most fleet owners track their tyres in notebooks. They don't know which tyre is underinflated, which needs rotation, which is approaching the scrap threshold, or which retreads are on which axle. The result is premature tyre failure, unplanned breakdowns, and a fuel economy stuck at 4.03 km/litre when better tyre management could push it to 4.5 km/litre — a 45% profitability effect.
Nobody had built software that addressed both sides of this problem — the retreading plant and the fleet owner — in a single connected platform.
Section 2 — What Was Built
iTRAMS — Intelligent Tyre and Retreading Advanced Management System — is a SaaS web and mobile platform that manages the complete tyre lifecycle from new tyre purchase through active service, retreading, and eventual recycling.
The platform has three core components working as one system:
The Tyre Management System (TMS) handles the fleet owner's side — vehicle logs, tyre pressure monitoring, tread depth (NSD) tracking, wheel balancing records, rotation schedules, inspection logs, mechanical and vehicle defect tracking, and real-time alerts. IoT sensors enable live pressure and temperature monitoring where hardware is deployed.
The Retreading Management System (RMS) handles the plant operator's side — intake inspection, sorting and job assignment, buffing, rasping, cementing, filling, building, curing, painting, storage, and delivery. Every stage is logged, time-tracked, and tied to a specific tyre casing ID. Image processing flags visual defects at key stages.
TNT Works is the service network layer connecting fleet owners to retreading plants and service centres, with online ordering, doorstep delivery, and a cost-per-kilometre (CPKM) pricing model that makes the economics transparent for fleet owners.
Analytics runs underneath all three layers — real-time dashboards showing KPIs, production throughput, raw material stock levels, financial overview, and customer data across the top 8 regions and client segments.
Tech stack: Android Studio and iOS Swift for mobile, Node.js backend, MongoDB database, GCP cloud, IoT hardware with plug-and-play sensors, low-code platform AppSheet for rapid prototyping and initial deployment.
Timeline: Research started in February 2020. Prototype built by April 2021.
Basic RMS and TMS were live by November 2021.
Beta product launched in June 2022.
Incubated at the Centre for Innovation and Incubation (CII), Utkal University. DPIIT-certified under Startup India.
Section 3 — Key Decisions
Decision 1: Start with the retreading plant, not the fleet owner.
The original instinct was to build the fleet owner TMS first — it's the more obvious product and the larger market. I chose to start with the RMS instead because the retreading plant operator is the supply-side constraint. If plants can't produce quality retreads reliably and at scale, there's nothing for fleet owners to buy. Fixing the supply side first also gave us a paying customer faster — plant operators have direct economic pain and smaller teams to onboard.
Trade-off: slower to reach fleet owners, but a higher-quality supply-side product by the time we did.
Decision 2: Prototype on low-code, rebuild for production.
The first prototype was built on a low-code platform, AppSheet (by Google), in January 2021. This was a deliberate decision to validate the workflow assumptions with real users before committing to full-stack development. Six months of real data collection and operator feedback identified five workflow assumptions that were wrong before a single line of production code was written.
Trade-off: the low-code prototype couldn't scale and had to be rebuilt. But it saved at least four months of building the wrong thing.
Decision 3: CPKM pricing model over pure SaaS subscription.
Most B2B SaaS products in this space charge a monthly subscription fee. We chose a cost-per-kilometre model — the customer pays based on usage, not a flat fee. This removed the upfront commitment barrier for price-sensitive fleet owners with 5–10 vehicles and aligned our revenue directly with value delivered.
Trade-off: harder to forecast revenue, slower to reach profitability, but significantly faster to customer adoption.
Decision 4: Build analytics from day one, not as a later feature.
Most small software builds treat analytics as a phase-two addition. We built the real-time dashboard as a core deliverable from the first prototype. This was the decision that drove the strongest customer retention — owners who saw their KPIs in real time were significantly less likely to churn than those using the operational features alone.
Trade-off: more complex initial build, but the analytics data became our primary sales tool for new customers.
Section 4 — What Broke
Failure 1: Staff digital literacy was the real adoption barrier, not the software.
The retreading plant workforce operates in a low-tech environment. Training staff to log tyre stages digitally rather than on paper took four to eight weeks per plant — far longer than anticipated. The biggest failure mode was not resistance to change but the gap between what staff were told to log and what they actually logged under time pressure. Incomplete data broke analytics quality and undermined owner confidence in the dashboards.
What I'd do differently: design a stripped-down data entry interface specifically for shop-floor workers — three taps maximum per tyre stage — before building the management dashboard. The management layer is only as good as the data entry layer below it.
Failure 2: The unorganised sector doesn't behave like a software customer.
The assumed customer journey was: owner sees demo, recognises value, subscribes, onboards team. The actual customer journey was: owner sees demo, agrees it's useful, delays decision for two months, partially onboards, reverts to paper when staff pushes back, calls support saying the app "doesn't work." This happened across multiple early customers.
The problem wasn't the product. It was that we were selling a behaviour change, not a software product. Unorganised MSME operators don't have change management capacity. The software required more organisational readiness than most customers had.
Failure 3: Post-COVID logistics slowdown hit at exactly the moment we were scaling.
By Q4 2022, the company had 250+ customers and was growing at 3x quarterly. The plan was to expand the TNT Works service network to cover highways beyond our initial Balasore–Bhubaneswar corridor. Instead, the logistics sector hit sustained margin compression post-COVID — freight rates stagnated, fleet operators cut discretionary spending, and new customer acquisition slowed sharply.
The timing was difficult to predict, but the concentration risk was real: we were entirely dependent on one industry going through structural stress.
Section 5 — Outcomes
Production failure rate at the pilot retreading plant dropped by 80% within six months of deployment through automated tracking of process stages and raw material quality.
Customer retention increased by 30% compared to the pre-software baseline — owners who could see real-time production status trusted the retreads they received.
Human intervention in plant management was reduced by 40% through automated job assignment, stage tracking, and digital inspection logs replacing manual paper-based systems.
Raw material wastage dropped to near-zero — real-time stock monitoring with expiry tracking on rubber compounds eliminated the previous practice of writing off expired stock monthly.
Scaled to 250+ enterprise customers across logistics, manufacturing, and fleet operations by Q4 2022 from zero in February 2020. 3x quarterly growth sustained for three consecutive quarters.
DPIIT-certified under Startup India. Incubated at CII, Utkal University.
Section 6 — What I'd Do Differently
I'd solve the behaviour change problem before the software problem. The product was technically sound, but the go-to-market assumed a level of digital readiness that most of our target customers didn't have. A lighter version — a WhatsApp-based logging system that required no app install, no training, and no change in physical workflow — would have onboarded the unorganised segment faster and generated the usage data needed to justify the full platform. I built the right product for the wrong adoption curve.
I'd also have built a stronger service layer from the start. The CPKM model was directionally right, but the execution required a physical service network — TNT Works — that was underfunded. Software alone doesn't solve a trust problem in an unorganised market. The service relationship is what earns the data relationship.
⚠️ Verdict: Smart but fragile at scale.
iTRAMS demonstrates that software can meaningfully improve tyre lifecycle management, reduce environmental waste, and increase fleet profitability — when deployed in motivated, digitally-ready operations.
The fundamental constraint is not technology. It is behaviour change capacity. India's retreading sector is 77% unorganised. The real scalability bottleneck is not the platform — it's onboarding 50,000 small plant operators who have never used software to run
their business.
This problem doesn't scale with better software. It scales with service-first distribution, embedded field support, and a decade-long market development programme. The technology is ready. The market isn't — yet.
Comments