Building a journey planner that scores train connections by "will I actually make it" — not just schedules
A year-ish ago I was trying to plan a train journey from Kanpur to Parbhani in India. No direct train. Had to break it into two legs with a change at Jhansi. Spent close to 2 hours across IRCTC, NTES, Google Maps, and a state transport site just trying to figure out if my connection buffer was actually safe or if I was setting myself up to get stranded.
That's the problem I'm building PivtTravel to solve.
The core idea:
Indian Railways carries ~23M passengers a day, but every existing tool (IRCTC, ixigo, RailYatri) treats routing as a static graph — find me a train from A to B. None of them answer the question that actually matters for multi-leg journeys: given how this specific train historically performs, what's the real probability I miss this connection?
So I'm building a scoring system (I call it P_miss) that uses historical delay data to label each connection Safe / Tight / Risky, instead of just showing a timetable and letting you guess.
On top of that: multimodal routing (discovering that getting off one station early and taking a 20-min bus unlocks a faster express), and station amenity mapping (where's the AC lounge if you're stuck waiting 2 hours at a junction) — both things current apps don't touch at all.
Where I actually am:
Landing page live, no backend yet. Pre-revenue, solo. Launched on Product Hunt a couple weeks ago — quiet result, didn't push the early-network-velocity hard enough in the first few hours, learned that the hard way. Verified on Google Search Console, basic analytics wired up.
What I've learned that's changed my thinking:
Found someone else independently building almost the same core insight — multi-train routing is hard, people avoid it. That's actually reassuring, not threatening — confirms the problem is real, not me overthinking a niche annoyance.
State transport data (the "multimodal" part of my pitch) is solid for trunk routes between bigger towns, but small-town feeder routes are mostly undigitized — paper timetables, depot knowledge, no API. That's a real constraint I'm scoping around rather than overpromising on.
Reddit threads about missed connections and TDR refund confusion are genuinely rare to find fresh — validated the pain exists, but it's not a high-volume complaint channel, more of an occasional confirmation signal.
What I'm trying to figure out next:
Whether to add waitlist/RAC confirmation probability as a feature (a much higher-frequency pain point than connection-safety, but a different problem to model) — or stay narrow and nail connection-safety + multimodal first.
Would genuinely love feedback from anyone who's dealt with Indian train travel, multi-leg journeys, or has built something in transit/logistics — what would make this actually useful to you vs. just another feature list?
I personally felt the same trouble while planning my journey with railways. Whenever I try to plan long journey, finding trains become headache. But I don't know how you are gonna manage the waiting list and delays?
Really glad this resonated — and yes, the waiting list question is the one I keep coming back to myself. Honest answer on where I am: the delay-based connection scoring (the Safe/Tight/Risky labels) is the core model I'm building first, using historical NTES delay data — so that part has a fairly clear path technically. Waitlist/RAC confirmation probability is a separate model entirely, but one I'm seriously considering adding because the frequency of that pain is so much higher than connection-safety — almost every booking on a popular route involves WL anxiety at some point. Still deciding whether to nail connection-safety first and layer WL prediction in later, or lead with WL since more people feel it more often. Curious — when you're planning a long journey, which frustrates you more: not knowing if your WL ticket will confirm, or not knowing if a connection is actually safe given how the trains historically run?