On this page · 12 sections
- What the aggregator rules actually put in your backlog
- The mapping bill is the line item people get wrong
- What a taxi app development company should be building
- How we deliver
- The stack we use, and why
- India-specific considerations: the state gig-worker laws
- What the driver side actually earns you
- Why eCorpIT
- How we engage
- FAQ
- How eCorpIT can help
- References
Summary. Since the Motor Vehicles Aggregator Guidelines came into force on 1 July 2025, most of a taxi app's feature list in India is written by regulation rather than by product managers. Dynamic pricing is boxed between 0.5x and 2x of a state-set base fare. Drivers on their own vehicles must receive at least 80% of the fare, and 60% on aggregator-owned vehicles. A licence costs ₹5 lakh, renewable every five years at ₹25,000, on top of a security deposit between ₹10 lakh and ₹50 lakh depending on fleet size. The app's cybersecurity has to be certified by a CERT-In recognised firm, and passenger data handled under the Digital Personal Data Protection Act 2023. Two numbers decide whether the economics work: the mapping bill, which on Google's India rate card starts at $1.50 per 1,000 route computations against $5.00 globally, and the driver-side monetisation model, which almost every large Indian operator changed between February 2025 and October 2025.
This page covers what we build, how we deliver it, and the specific decisions that cost operators money when they get them wrong.
What the aggregator rules actually put in your backlog
Most vendors sell a taxi app as a three-app bundle: rider, driver, admin. That is accurate and incomplete. In India the licence conditions add a set of features that have nothing to do with booking a cab, and skipping them is what gets an aggregator's licence suspended for up to three months.
| Requirement under MVAG 2025 | What it means in the build |
|---|---|
| Fare between 0.5x and 2x base fare, base chargeable for a minimum 3 km | Pricing engine needs a state-configurable floor, ceiling and dead-mileage rule, not a single surge multiplier |
| Driver receives 80% own vehicle, 60% aggregator-owned | Two settlement paths, with the split disclosed in-app before the driver accepts |
| Vehicle Location Tracking Device feed to the state command and control centre | An outbound telemetry integration per state, separate from your own tracking |
| Route deviation triggers a control-room alert | Server-side geofence comparison against the quoted polyline, plus an operator console |
| Driver identity verification against the police-verified record | Face match at login, high-resolution driver photo in the rider app |
| Cybersecurity certified by a CERT-In recognised firm | A penetration test and remediation cycle before launch, budgeted as a line item |
| Grievance officer, 24x7 control room, three-day complaint inquiry | Ticketing with a hard SLA clock, not a shared inbox |
| Driver contact retained and reachable for seven days after a trip | Number-masking service with a seven-day retention window under DPDP |
Two of these are routinely missed in fixed-price quotes. The command-and-control-centre feed is a per-state integration, so a launch in three states is three integrations. And the 40-hour driver induction programme, which must combine in-person and virtual sessions and cover gender and disability modules, usually means a small learning module with completion tracking, because the training structure has to be uploaded to the designated portal.
Vehicles more than eight years old from first registration cannot be onboarded, which is a validation rule against the registration certificate rather than a manual check. Aggregators also cannot stop drivers working on competing platforms, so any design that assumes exclusivity is non-compliant as well as commercially optimistic.
The mapping bill is the line item people get wrong
Routing, map rendering and address autocomplete are usually the largest recurring third-party cost in a ride-hailing app, and the pricing is easy to misread. Google Maps Platform publishes a separate rate card for India, available to accounts billed in India with a large majority of usage in India. Both lists are quoted in US dollars; the India list is not a currency conversion, it is a lower rate card.
| SKU | India first paid tier | Global first paid tier | India free cap |
|---|---|---|---|
| Compute Routes Essentials | $1.50 / 1,000 | $5.00 / 1,000 | 70,000 |
| Compute Route Matrix Essentials | $1.50 / 1,000 | $5.00 / 1,000 | 70,000 |
| Dynamic Maps | $2.10 / 1,000 | $7.00 / 1,000 | 70,000 |
| Autocomplete Requests | $0.85 / 1,000 | $2.83 / 1,000 | 70,000 |
| Geocoding | $1.50 / 1,000 | $5.00 / 1,000 | 70,000 |
| Navigation Request | $8.00 / 1,000 | $25.00 / 1,000 | 7,000 |
| Roads, Nearest Road | $3.00 / 1,000 | $10.00 / 1,000 | 35,000 |
Rates as published on 11 August 2026. Three details in that table decide the bill.
Route Matrix bills per element, not per request. A 25 by 25 matrix is 625 billable events, so the 70,000 free cap is about 112 matrix calls. Dispatch systems that recompute a full driver-to-rider matrix on every request burn the free tier in a morning. Shortlist candidate drivers with a cheap geospatial query first, then compute the matrix only over that shortlist.
Navigation Request bills per destination, and its India free cap is 7,000 against 70,000 for the other Essentials SKUs. Multi-stop trips bill once per stop.
The India discount is a low-volume and mid-volume effect. Above 5,000,000 billable events a month the two rate cards converge exactly, at $0.38 for route computations and $2.00 for navigation requests. A cost model built on India rates that projects growth past that point has to switch rate cards, or it will understate the bill. Accounts on India pricing also cannot enrol in Google's subscription plans, so the $100, $275 and $1,200 monthly bundles are not an option.
The mapping bill is a function of architecture, not of traffic. Caching geocodes, using session tokens correctly for autocomplete and keeping matrix calls narrow will move it more than any negotiation.
What a taxi app development company should be building
Our work on ride-hailing and on-demand products covers four surfaces.
The rider app handles booking, fare estimation against the state fare structure, live tracking, live location sharing during the ride, in-app rating, and the accessibility features the guidelines require. The driver app covers onboarding with document capture, identity match at login, the trip lifecycle, earnings and payout visibility with the fare split disclosed, and the induction and refresher training flow. The operations console gives the control room live vehicle positions, panic-button and route-deviation alerts, the grievance queue with its inquiry clock, and driver and vehicle compliance status. Behind those sit dispatch and matching, the pricing engine, payments and driver payouts, and the telemetry pipeline.
Dispatch is where most rebuilds start. A matching service that scans every online driver on every request is fine at 200 rides a day and falls over at 20,000. We build matching on a geospatial index with a candidate shortlist, then score that shortlist on estimated time of arrival, driver acceptance history and fare fairness, which also keeps the route matrix cost bounded.
How we deliver
We run taxi and on-demand builds in five steps.
First, a discovery and compliance mapping week. We turn the licence conditions for your launch states into a feature list and an integration list, because the command-and-control-centre feed and the fare structure differ by state.
Second, architecture and cost modelling against your projected ride volume, using the published rate cards, before application code is written. This is the step that changes designs, and a dispatch design is cheaper to change on a whiteboard.
Third, a working core: booking, dispatch, tracking, fare calculation and payouts, deployed on production-shaped infrastructure with observability from day one rather than added later.
Fourth, the compliance and safety surface. Panic button, route deviation, number masking with its retention window, the grievance console with SLA timers, and the CERT-In certified security assessment with its remediation cycle.
Fifth, pilot and scale. A single-city pilot with a small driver cohort, then load testing against the dispatch path, then rollout. Onboarding vehicles and drivers at volume is an operational problem as much as a technical one, and the admin tooling usually needs the most iteration.
The stack we use, and why
For the client apps we build in Flutter or React Native when one team should ship both platforms, and native Kotlin or Swift when background location accuracy and battery behaviour dominate, which on a driver app they often do. Continuous background location on Android is the most common source of driver-app complaints, and it is a platform problem before it is a product problem.
Server side we use Node.js or Go for the dispatch and trip services, PostgreSQL with PostGIS for geospatial queries, Redis for driver location state and matching, and Kafka or a managed equivalent for the event stream that feeds both your analytics and the state tracking obligation. Payments run through a licensed payment aggregator and driver payouts through a payout API, which matters because the Reserve Bank of India's payment aggregator framework requires settlement through escrow accounts.
India-specific considerations: the state gig-worker laws
Ride-hailing operators now face state-level welfare levies, and the product obligations attached to them are the part that reaches the backlog.
Karnataka is the one collecting. The Platform Based Gig Workers Act allows a welfare fee of 1% to 5% of the payout made to a gig worker per transaction, and the state fixed it at 1%, the lowest the law permits, in an order published in the official gazette on 13 February 2026. The amount is then capped in rupees by vehicle category: ₹0.50 for two-wheelers, ₹0.75 for three-wheelers and ₹1.00 for four-wheelers. On a ₹400 cab fare that cap makes the effective levy about 0.25%, not 1%. Anyone modelling this as 1% of gross bookings will overstate the liability several times over. Aggregators self-declare and deposit the fee within five working days of each quarter end, and transactions are tracked through a state-run Payment and Welfare Fee Verification System, so the reporting obligation reaches your payout ledger.
Two Karnataka provisions are product requirements rather than finance ones. Section 14(2) of the Act bars deactivating a worker without written reasons and 14 days' notice, so account suspension needs a notice workflow and an audit trail. Rule 10(2) of the Rules notified on 19 November 2025 requires the platform to answer a gig worker's query about automated decisions within five working days. The draft rules had said 30 working days, and commentary published before 19 November 2025 still quotes the older figure.
What drivers want protected is narrower than the debate suggests. Ajay Kumar, Partner at Triumvir Law, told MediaNama: "They want the payout details and they want the performance metrics to be protected. In such a way that, tomorrow you stop using the app and you come back after three months, you shouldn't start from zero." Rating and earnings history portability is a data-model decision, and it is far cheaper to make at design time.
Telangana enacted its own Act, which received assent on 25 April 2026, but the rate is left to be notified and no percentage appears in the statute. Its termination notice period is seven days, against Karnataka's fourteen, which is a real difference to build for if you operate in both. Jharkhand's Act, issued on 6 January 2026, levies 1% to 2% of annual turnover excluding taxes rather than a per-payout fee. Rajasthan's 2023 Act contains no percentage at all; the widely repeated "1% to 2% of each transaction" figure attributed to it is not in the enacted text.
What the driver side actually earns you
The commission model most business plans assume has largely been replaced. Ola extended a zero-commission plan to cab drivers in June 2025, with a 30-day pass at ₹2,010, about ₹67 a day. Uber moved auto-rickshaws to a software fee of ₹20 to ₹40 a day in February 2025, then told Business Standard in October 2025 that it runs "a subscription model across all form factors, including cars, autos, and bikes". Rapido, which moved first, charges a daily access fee reported at ₹9 to ₹29.
The reason is partly tax. Under the commission model the platform charges 5% GST without input tax credit or 12% with it. Under the software-as-a-service model the 18% GST falls on the driver. Whichever you choose changes your invoicing, your GST registration position and your driver payout logic, so it is an architecture decision as much as a pricing one. Published commission figures vary widely and are contested: TechCrunch put Uber's historic commission at 25% to 40% of the fare, while Business Standard reported 15% to 20%. Treat any single number you are quoted with suspicion.
Why eCorpIT
We are a Gurugram-based engineering organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, working with senior-led teams rather than a staffing pool. Our relevant experience is in on-demand and location-heavy products: dispatch and matching systems, high-frequency location pipelines, payment and payout integration, and the compliance surface Indian operators have to build. We also build the adjacent categories, including on-demand app development, food delivery app development and ecommerce app development, which share the same dispatch, tracking and payout problems.
We publish our cost models rather than hiding them, as the mapping table above shows. Where a regulation is unclear, we say so instead of inventing certainty. The DPDP obligations that come with passenger and journey data are covered in our DPDP Act engineering playbook, and our wider mobile practice is described on our mobile app development company in Gurgaon page.
How we engage
Three models, chosen by where the risk sits. A fixed-scope pilot suits a single-city launch with a defined feature list and a fixed timeline, and is the usual starting point. A dedicated team suits multi-state rollouts where the compliance surface keeps changing and scope cannot be frozen. A build-operate-transfer arrangement suits operators who intend to bring engineering in-house after launch, where we build and run the platform and hand over the team and the documentation on an agreed date.
Cost depends on the number of states at launch, whether you need bike and auto form factors alongside cabs, and how much of the operations console you need on day one. We scope after a discovery week rather than quoting from a feature checklist, because the state count moves the number more than the feature list does.
FAQ
How eCorpIT can help
We build taxi, ride-hailing and on-demand platforms for Indian and international operators, from a single-city pilot through to multi-state rollouts. Our discovery week turns your launch states into a concrete feature list, integration list and third-party cost model before any application code is written, which is where most budget overruns are avoided. If you are scoping a ride-hailing build or replatforming one that has stopped scaling, contact us and we will walk through the compliance surface and the cost model for your specific states.
References
Last updated: 15 August 2026.
