commutify

I am building the website of Delhi Metro, where I can get the fastest route to commute and the best way to reach faster. If any item is lost on the metro station, you can complain to us; we help to find your items within 24 hours. Compare your price with other conveniences like buses and cars and find the cheapest one.

Priya works in Gurugram, lives in Rohini. Every morning she takes a DTC bus to the nearest metro, rides the Yellow Line with two interchanges, and walks the last 800m to her office. Three things quietly fail her every single day:

1. She overpays or underpays because DMRC's flat distance-slab fare doesn't reflect how bad her specific route is — two interchanges and peak crowding cost her real time, but her ticket costs the same as someone with a direct, empty ride.
2. Last week she left her earphones on the train. She filed a lost-item report and got a robotic "your complaint has been registered" message — no idea where to look, no timeline, no hope.
3. Her bus to the metro station is "on the way" for 20 minutes, so she either leaves too early and wastes time, or too late and misses her train — because the bus and the metro have never once talked to each other.

That's the whole pitch in one sentence: Delhi's commute is three disconnected systems pretending to be one journey.

Act 2 — The Turn (this is where your project walks on stage)

You're not building three separate features. You're building the thing that finally makes DMRC fare, DTC buses, and lost-and-found behave like they know Priya exists.

Feature 1 — Fair Fare, not just Flat Fare

Right now DMRC prices purely on distance slabs. Your project layers a fairness/reliability score on top of the real fare table we already built (delhi_metro_fares.csv):

• Take interchanges + historical crowding/delay-risk (from the ridership dataset) → compute a "Journey Friction Score" per route.
• Pitch line: "Two passengers pay the same ₹43 — one gets a direct 20-minute ride, the other gets 2 interchanges and a 40-minute ordeal. We don't change DMRC's official price — we make the friction visible, so commuters can choose smarter routes and DMRC gets data to justify targeted improvements on the worst-friction interchanges."
• This is smarter than "we'll change the price" (which you can't actually do, and judges will call out) — you're pitching a transparency + optimization layer, which is realistic and fundable.

Feature 2 — Lost & Found that talks like a human, not a ticket system

Replace the dead "complaint registered" message with a status narrative that mirrors what airlines do with baggage:

"Your earphones were last scanned near Rajiv Chowk at 6:42 PM. Items reported on the Yellow Line are typically recovered within 18 hours. We've flagged Rajiv Chowk and Hauz Khas security desks — you'll get a photo confirmation the moment it's found."

Built from the Lost & Found dataset: station + time-of-report density lets you generate a realistic recovery-time estimate per station/line, not a generic "we'll get back to you." This turns anxiety into a countdown — that's the emotional beat your demo needs.

Feature 3 — DTC + Metro, one countdown instead of two guesses

This is your connective tissue, literally:

• Cross-reference DTC bus ETA (GTFS-style feed, or simulate with realistic headway data) against metro departure times at the interchange station.
• Pitch line: "Instead of 'bus in 12 min' and 'train in 6 min' as two separate numbers Priya has to do math on, we tell her: leave now, you'll make the 8:14 train with 2 minutes to spare."
• This is the feature that makes judges say "oh, that's actually useful" — because it solves the one thing nobody has solved: first/last-mile handoff timing.

Built With

• agent
• ai
• cloud
• elastic