For most Indian mobility platforms, the metro-first playbook was gospel: build for Bengaluru, Delhi and Mumbai, then port the same product downstream. Rapido tore that playbook up. Nearly a third of the company’s business now comes from Tier 2 and Tier 3 cities, and getting there meant rethinking the platform almost from the ground up — not just the app’s interface, but the matching engines, pricing logic, and infrastructure decisions underneath it.
“Close to 30% of our business comes from Tier 2 and Tier 3 cities, and a lot of the assumptions that worked in metros simply didn’t hold once we moved into smaller markets,” says Srivatsa Katta, CTO of
Designing for the Phone People Actually Have
The second assumption to fall was about the hardware and networks Rapido’s users would be running on. Metro-first design tends to assume a recent smartphone and dependable 4G. Neither holds outside India’s biggest cities. “We couldn’t assume users had the latest smartphones or reliable network coverage, so the app itself had to get lighter, more resilient to network drops, less data-intensive, and built to work well even on lower-end devices,” Katta says.
Language, too, turned out to be more than a localization checkbox. “Language turned out to matter more than we initially expected, and not just as a translation exercise,” he notes. “It meant rethinking voice inputs, icons, and the entire user flow so that someone who isn’t comfortable reading English could still navigate the app intuitively.”
Crucially, Rapido didn’t rebuild its product every time it entered a new city — because it never built the product as a single monolith to begin with. “We designed the core system — matching, pricing, demand forecasting — as a modular platform from day one,” Katta says. “So entering a new city today looks a lot more like configuration than reinvention.” That architectural choice — modularity over customization — is arguably the single biggest reason Rapido’s Tier 2/3 expansion has scaled as fast as it has.
The Matching Engine: Where AI Meets the Bottom Line
Ask Katta where AI is actually moving the needle today, and he doesn’t point to a flashy generative AI feature — he points to plumbing. “Today, the most meaningful impact of AI is visible in the matching engine,” he says. “It processes a large volume of requests every minute and matches riders and captains within seconds. This speed and accuracy, driven largely by AI, has significantly reduced wasted travel for captains.”
That reduction in “dead kilometres” — the unpaid distance captains travel between rides — is more than an efficiency metric. It flows directly into captain earnings, which Katta frames as the real objective behind Rapido’s AI investment. “The matching engine is arguably the most significant of these [initiatives], as it operates in real time and factors in location, traffic, and captain availability. This has made a considerable difference in reducing dead kilometres, which matters a great deal for captain earnings.”
Sitting alongside matching is demand forecasting — a system that ingests weather, local events, and historical ride data to build demand maps that refresh in near real time. “Demand forecasting is another key initiative, drawing on factors such as weather and local events, along with ride history, to build demand maps that update in near real time, allowing captains to make informed decisions about where to be rather than relying on guesswork,” Katta says.
From Reactive Rides to Predictable Incomes
Rapido’s north star metric isn’t ride volume — it’s income predictability for its captains, and Katta is explicit that this reframes how AI gets applied. “We aim to consider a captain’s entire working day, rather than focusing on a single ride in isolation,” he says. Demand maps feed directly into zone suggestions inside the app, and the payoff is measurable: “Captains who follow these suggestions tend to complete a greater number of trips during peak hours, which naturally results in less time spent waiting.”
Underpinning that is a policy layer — the Minimum Support Price — that acts as an earnings floor when the AI’s predictions don’t pan out on a given day. “The Minimum Support Price functions as a safety net, ensuring that a captain is not left without earnings even if a particular shift does not go well,” Katta says. And on the core question of predictive power, he doesn’t hedge: “We are able to generate a fairly reliable estimate of where and when a captain is likely to find work, based on time of day, location patterns, and seasonal trends, and this forms the basis of the zone suggestions already available within the application today.”
Architecture Built for Millions of Real-Time Decisions
Scaling a system that has to make millions of matching, routing, and pricing decisions a minute — without breaking under national scale — has forced Rapido into a strict separation of real-time and heavy compute workloads.
“The matching engine must process a substantial volume of requests every minute while still responding within seconds, so we rely heavily on systems designed for speed and structured around location, given that mobility decisions are inherently tied to place,” Katta says. “Heavier workloads, such as training our forecasting models, are run separately to ensure they do not affect real-time performance.”
That same modularity that eased geographic expansion also protects reliability in low-connectivity markets. “We have also built the platform to be modular, so that when entering a new city, particularly one with weaker connectivity, we are adapting existing systems rather than building from scratch,” he says, adding that Rapido has deliberately engineered for graceful degradation: “in areas with poor network conditions, the application degrades gracefully rather than failing outright.” Much of this runs on infrastructure Rapido controls directly — “self-managed, elastic, and highly resilient” — built to flex with demand swings through the day rather than being provisioned for peak load around the clock.
A Platform for Gig Work, Not Just Rides
Perhaps the most consequential answer Katta gives is about identity — not Rapido’s product roadmap, but what kind of company it believes itself to be. “We would lean toward describing ourselves as building [a technology platform for distributed mobility and gig work], even though mobility is where the company began,” he says.
In his telling, the real-time matching, demand prediction, and income-stabilization tools Rapido has built aren’t ride-hailing features at all: “they represent building blocks capable of supporting other forms of gig work as well.”
Looking out five years, Katta lays out a capability roadmap that reads more like an AI infrastructure strategy than a mobility one: “location intelligence that functions reliably in areas with patchy connectivity, AI that simplifies captains’ work without undermining their judgment, and improved tools to help individuals predict and plan their earnings rather than relying on hope for a good day.” Voice-based onboarding, support and multilingual interaction also feature prominently in that vision — not as accessibility add-ons, but as core UX, since, as he puts it, they “allow captains to remain focused on the road rather than constantly engaging with a screen.”
“We are also reimagining how AI technology can power our products for end users,” Katta says, “so that using the product feels considerably more natural, thereby reducing friction, which is essential as we continue to expand into these markets.”
For an industry that often measures AI maturity in chatbots and generative features, Rapido’s story is a reminder that the highest-leverage AI investment can be the least visible one: a matching engine, a forecasting model, and an architecture built to survive a network drop in a Tier 3 town — not because it’s glamorous, but because that’s where the next hundred million users actually are.