Two apps sit on the phones of a lot of Pune commuters. Apli PMPML, built by Chartr Mobility for the city bus service, has passed a million downloads and sits at 3.4 stars across roughly 9,600 reviews. The Pune Metro official app from Mahametro has crossed half a million downloads with 3.6 stars from about 1,680 reviews.
Neither rating is where anyone wants it. The easy conclusion is that the teams behind them didn’t do a good job.
That conclusion is wrong, and it’s worth explaining why, because the problems these apps run into are among the harder ones in mobile development. Chalo, which does a broadly similar job, manages 4.1 on the same store, so the difficulties are clearly solvable. But they’re solvable through specific engineering decisions that have to be made early, and if you’re planning anything in this space, these are the decisions worth getting right the first time.
We’ve read through the public reviews on both apps. The complaints cluster tightly, which is useful, because it points straight at the four things that actually break.
Key Takeaway: Transit apps fail on four predictable fronts: payments that take money without issuing a ticket, functionality that dies where there’s no signal, live tracking that projects false confidence, and sessions that make users log in constantly. All four are design decisions made before a line of code gets written, not bugs to fix afterwards.
The Payment Problem That Nobody Gets Right First Time
The single loudest complaint across both apps is the same one. Money leaves the account and no ticket arrives. On the Metro app the most upvoted reviews describe exactly this, with one adding that once a grievance is raised there’s no way to check what happened to it.
Here’s why this is genuinely difficult rather than careless.
Buying a ticket looks like one action to the user. Underneath it’s a conversation between at least three systems: the app, a payment gateway, and the ticketing backend. Money moves in one system while the ticket is created in another, and there’s no shared transaction wrapping both. If the network drops in the gap, and on a crowded platform it will, the payment can succeed while the ticket creation never happens. Nobody wrote a bug. The design simply had no answer for that moment.
The fix is a set of practices that are well understood and often skipped when a deadline is close.
Every payment attempt carries an idempotency key, a unique identifier generated by the app before the request goes out. If the app retries because it lost the response, the gateway recognises the key and refuses to charge twice. This one decision eliminates a whole category of duplicate charges.
Behind that, a reconciliation job runs continuously, comparing what the gateway says it collected against what the ticketing system says it issued. Anything that doesn’t match gets resolved automatically, either by issuing the ticket or refunding, within a stated window. The user should never be the mechanism that discovers the mismatch.
And the interface has to be honest about the in-between state. “We’re confirming your payment, this takes up to two minutes” is a fine thing to show someone. Silence is not, and neither is a success screen the system isn’t sure about. Most anger in those reviews isn’t about money being lost. It’s about not knowing what happened.
This is the same discipline any fintech build needs, and it’s the part where cutting corners costs the most trust.
Underground, With No Signal
A metro app has to work in the one place phones don’t. Platforms are below ground, tunnels have no coverage, and the moment a commuter most needs their ticket is the moment their connection is worst. Reviews of the Metro app mention it behaving badly on poor networks, which for this category is close to a definition of the problem.
Designing around it means the QR ticket has to be generated and verified without a live server call. That’s achievable with cryptographically signed tokens: the ticket carries its own proof of validity, the gate validates the signature locally, and reconciliation happens later when both sides have connectivity. The ticket exists on the device from the moment it’s bought, not fetched when it’s scanned.
Everything else follows the same rule. Fares, station lists, route maps and the user’s active passes get cached on the device and refreshed opportunistically. The app should open and be useful with the radio off. Anything that genuinely requires a connection should say so plainly rather than spinning.
We make the same argument about factory apps in Pune, where plant wifi dies near heavy machinery. Different setting, identical engineering. Offline is an architecture, decided at the start. It cannot be added later without rewriting most of the app.
Live Tracking Is a Data Problem, Not a Map Problem
The PMPML reviews are specific and consistent about tracking. Buses appear on the map with one route number and arrive showing another. Buses don’t appear at all and then turn up at the stop. Predicted timings are unreliable. The most upvoted review on the listing makes exactly these points, and it’s rated helpful by dozens of people.
Putting a moving dot on a map is the easy part. Everything upstream of that dot is where it gets hard.
GPS drifts in dense areas with tall buildings. Tracking hardware on a vehicle can be switched off, unplugged or simply broken, and no one on the software side finds out. Buses get reassigned between routes during a shift for entirely sensible operational reasons, so the vehicle reporting itself as route 134 may genuinely be running something else now. And predicting arrival time in Pune traffic is a forecasting problem, not a geometry one.
None of that can be fixed purely in the app. It needs data quality work at the source, on the vehicles and in the depot systems. What the app can do, and what separates the good ones, is stop projecting confidence it doesn’t have.
Show when a position was last updated. Show a range rather than a single minute when the confidence is low. Mark a vehicle as stale instead of leaving a dot sitting on a road it left twenty minutes ago. Users are surprisingly tolerant of “we’re not sure”. They are not tolerant of being told something confidently and finding out it was wrong while standing at a bus stop.
That’s a product decision more than a technical one, and it’s the one we’d argue hardest for.
The Login Question
Several Metro app reviews complain about having to log in every time the app opens. It’s an easy thing to criticise and a less easy thing to solve well, because there’s a real reason behind it. The app holds payment methods and issues things of value. Long-lived sessions on a device that gets lent, lost or shared are a genuine risk.
The answer isn’t to choose between security and convenience. It’s to separate them. A refresh token can keep someone signed in for weeks while the app still demands a fresh check at the moment it matters, which is payment. Biometric re-authentication handles that in under a second, so the sensitive action is protected without punishing someone who just wants to look up a fare.
Making the user prove who they are in order to read a timetable protects nothing. Step up the authentication where the risk actually sits.
What the Data Safety Labels Say
There’s a detail on both listings that most people scroll past, and it’s worth a look because Google puts it in front of every prospective user.
Apli PMPML declares that data is encrypted in transit, and also that data can’t be deleted. The Pune Metro app declares the reverse: users can request deletion, but data isn’t encrypted in transit.
Each has one half of the pair right. Taken together they’re a neat illustration of how these labels drift out of step with what an app should be doing, particularly with India’s Digital Personal Data Protection Act pushing deletion rights toward being a baseline expectation rather than a nice extra. Encryption in transit, meanwhile, has been standard practice for years and is close to free to implement.
These declarations are written by the developer, and they’re often filled in once during a release and never revisited. If you’re shipping an app, they’re worth an annual look, because they’re read by users deciding whether to install and increasingly by people with a compliance interest.
What Good Looks Like Here
Chalo runs at 4.1 across the same category, which tells you the ceiling is higher than 3.4 or 3.6. Looking at what tends to separate the better transit apps, it isn’t feature count. It’s that the core loop, find your service and pay for it, works every single time under bad conditions.
That’s an unglamorous kind of quality. It doesn’t demo well and it’s hard to put on a feature list. It’s also the entire basis on which people rate these apps, because a commuter uses one function twice a day and judges the whole product on whether it worked.
If You’re Building Something in This Space
A short list of what we’d insist on from the start.
Design the failure paths before the happy path. What the user sees when the payment is uncertain matters more than what they see when it works.
Treat offline as the default state and connectivity as the exception. It’s much cheaper to relax that assumption later than to introduce it.
Never show confident data you can’t stand behind. Timestamps and ranges beat false precision.
Build reconciliation and automatic refunds on day one, with a stated resolution window. Then say what that window is inside the app.
Test on a four-year-old budget Android phone on a throttled connection, not on the newest device on office wifi. That’s the actual environment.
And put a real support path in the app, with a reference number and a status the user can check. A large share of one-star reviews on both apps are about not being able to find out what happened, rather than about the original failure.
Common Questions
How much does a transit or ticketing app cost to build? A focused ticketing app with payments and offline QR generally runs ₹8 to 20 lakhs depending on the integrations. Live vehicle tracking adds meaningfully to that, because the hard cost sits in the data pipeline and the depot side rather than in the app. Our Pune cost comparison covers general ranges.
How long does it take? Four to seven months for a first version that handles payments and offline tickets properly. Rushing the payment reconciliation to hit a launch date is the most expensive shortcut available in this category.
Can one app cover buses and metro? Technically yes, and commuters clearly want it. The obstacle is usually organisational rather than technical, since it needs two operators to agree on fare handling, revenue splits and support ownership.
What’s the hardest part? Payments under unreliable networks, without question. Everything else has a well-trodden solution.
How do you test offline behaviour properly? Not with a wifi toggle. You need network conditioning that simulates high latency and packet loss, plus deliberate mid-transaction kills, on real devices. Airplane mode tests the easy case and misses the failures that actually happen.
Why We Wrote This
We build apps in Pune, and we use these apps like everyone else here. Nothing above is meant as a shot at the teams involved. Both apps do things well, both are shipping updates, and the problems they’re wrestling with are the ones that make this category difficult in the first place.
If you’re planning something with real-time data, payments over patchy connections, or offline requirements, those are the areas where a build goes wrong quietly and expensively. Our case study on StockGenie covers a project where getting real-time data right was the bulk of the work. If you want to talk through an idea in this space, get in touch.