Inspiration

Problem: Railway food apps already show a train's delay, but a late train can still end in dead ends such as "No items available right now" or "No stations available", with no reason and no next step. This affects every passenger whose train is delayed.

I ran into this at New Delhi station, waiting for a train that was 2 to 3 hours late. I had no local cash and relied on digital payments, so I tried to order food through food apps. They would not let me. While building this project I checked a delayed train again on existing railway food apps and saw similar dead ends.

What it does

RailDrop is a concept feature for IRCTC eCatering. It is not the real app.

  • The order-by time follows the live arrival estimate, so it moves when the train gets later.
  • It answers "Can I order right now?" and shows what a cutoff based on the printed timetable would have done.
  • A closed restaurant explains why, and the app points to the earliest station that still works.
  • A passenger waiting at the boarding station can still order.
  • After ordering, the restaurant gets an updated "start cooking at" time when the delay changes. If a delay pushes arrival past closing time, the passenger gets a clear message and a refund (simulated).

Before: the order window closes and the passenger sees an empty page, for example "No restaurants serving here", with no reason. After: the passenger sees whether they can order now, how long they have, why a restaurant is closed, and what to do next. The app also has a "How is this different from ordering today?" screen.

How we built it

React, Vite, Tailwind CSS and JavaScript, hosted on Vercel, with the code on GitHub. All trains, restaurants and prices are sample data.

  • Order-by time = train arrival estimate - cooking time - 30 minutes.
  • Cooking start = arrival estimate - cooking time - 10 minutes.
  • A restaurant can deliver only if it is open at the arrival time and the order-by time has not passed.

The demo timeline starts from your device's current time. A "Demo controls" button stands in for the live train feed, so you can watch the app react to a delay.

AI coding assistants (mainly Claude) helped during development. The running app calls no AI model.

Challenges we ran into

  • I could not verify how real apps decide their cutoffs, so the order-by rule is my own assumption.
  • There is no free live train feed or real restaurant data, so I used sample data and a simulated delay.
  • My first demo used a made-up clock and felt fake. I changed it to start from the current time.
  • Times that pass midnight, and keeping many screens consistent when the delay changes.

Accomplishments that we're proud of

  • The whole flow works end to end: PNR, journey, stations, restaurants, menu, cart, payment, order tracking and a restaurant view.
  • One clear screen that shows the idea: a timetable-based cutoff would already have closed, while the live arrival time keeps ordering open.
  • It handles the case it cannot fix honestly, with a clear message and a refund.

What we learned

This problem is mostly about decision rules and clear messages, not extra features. Showing the reason and the next step matters as much as the cutoff itself. I also learned to be open about what is simulated.

What's next for RailDrop: live order window for IRCTC eCatering

  • Check the real cutoff rules and connect to a live running-status feed and real restaurant hours.
  • Build the restaurant-side view for real, with "start cooking at" updates.
  • Decide who pays for food already cooked when a delay changes late.
  • Handle very short station halts and add more languages for passengers.

Timeline and credits

A basic first version of the idea was started before the hacking window. The features above were built during Oct 20 to 27, 2026. The organizers confirmed by email on Oct 24 that this project can be submitted. Not affiliated with or endorsed by IRCTC.

Built With

Share this project:

Updates

Submission history