Building less: what real MetroPing users taught me
Volunteer testers changed the interface, the permission flow, and the roadmap. They also taught me why removing features can improve a product.
What building MetroPing taught me.
Concrete lessons from real Delhi Metro journeys, volunteer feedback, technical limits, and product decisions made during the beta.
Real journey testingVolunteer feedbackTrade-offs stated clearly
FROM THE BUILD
Lessons from the beta
Why real metro testing matters more than simulator success
A simulator can validate screens and predictable routes. Only a moving train exposes underground signals, background limits, and device behaviour together.
AI made MetroPing faster to build, not easier to trust
AI accelerated ideas, debugging, and repetitive work. Trust still had to be earned on moving Delhi Metro trains.
Why reliability came first when most feedback was about UI and UX
The design feedback was valid, but a journey app first has to deliver a timely alert without excessive battery use.
Showing 4 of 7 articles
FROM LINKEDIN
Short notes from the build.
Three posts about product decisions, tester feedback, and the commuter problem behind the beta.
01
Why I stopped adding every requested feature
The product filter I use before deciding whether a new idea belongs in MetroPing.
Read on LinkedIn 02Why reliability came before visual polish
What I prioritised after most tester feedback focused on UI and UX.
Read on LinkedIn 03Would commuters actually use MetroPing?
The Delhi Metro journey problem the beta is designed to validate.
Read on LinkedIn