About RailSetu

One waitlisted ticket.
A route that still works.

RailSetu is a passenger-first journey planner for Indian train travellers. When a direct ticket is waitlisted, it looks for confirmed segments on the same train and explains the changes as one simple journey.

The problem

Availability is fragmented. The journey should not be.

A berth may be unavailable from point A to B even when confirmed seats exist across smaller parts of that exact route. Finding those combinations manually is slow, confusing and easy to get wrong.

The idea

Stay on the train. Change only what is necessary.

RailSetu searches for a continuous chain of confirmed segments, then makes every seat or coach transition visible before the traveller chooses it.

How the engine thinks

From scattered seats to one clear plan.

01

Map the whole train

Read availability across the train’s route, not only the requested origin and destination.

02

Join confirmed segments

Build continuous options that keep the traveller on the same train while seats or coaches change.

03

Rank for the person

Filter by mobility, luggage, family needs and comfortable interchange time before showing the clearest route.

Built around the traveller

The shortest route is not always the right route.

Comfort Score, in the simplest words

How easy will this journey feel?

Think of it as an effort meter, not a promise that a ticket will be confirmed.

89out of 100Very comfortable
  1. 1
    Start at 100.

    A simple journey begins with a full score.

  2. 2
    Small chores remove points.

    Changing seats, managing another ticket, walking to a different coach, moving at night, or getting the wrong berth makes the number smaller.

  3. 3
    Your needs decide how much.

    The same change matters more for an elderly traveller, a family, or someone carrying heavy luggage. Staying in one coach or matching a requested lower berth can add a few points back.

90–100Very easy80–89Comfortable65–79ManageableBelow 65More effort

Big number = easier journey. RailSetu uses it to rank valid paths; it never replaces live availability or a booking confirmation. See the full calculation →

Cancelled-ticket refunds

Earlier cancellations usually mean a larger refund.

For confirmed tickets, RailSetu estimates the deduction using IRCTC's time bands: a class-based charge more than 48 hours before departure, 25% from 48–12 hours, 50% from 12–4 hours, and no refund inside four hours. Minimum charges and GST may apply. The Wallet destination is a prototype convenience; official e-ticket refunds normally return to the original payment account. Read the official rules ↗

What the build makes obvious

Six questions.
Clear answers.

RailSetu is designed so the problem, the intervention and the prototype's limits are visible without a pitch.

01

Who is facing the problem?

Indian train travellers whose direct option is waitlisted—especially elderly passengers, families, people with limited mobility and anyone carrying luggage who cannot treat every seat or coach change as equally easy.

02

What is difficult about the current experience?

Availability is usually checked as one origin-to-destination request. Confirmed berths across consecutive portions of the same train remain hidden, leaving travellers to repeat searches, compare stations and verify continuity manually.

03

What did RailSetu change?

RailSetu treats a train route as a chain of bookable segments. It joins confirmed segments on the same train, filters them against traveller constraints and explains the station, time, coach and seat involved in every change.

04

Why is this version better?

It turns fragmented availability into one understandable journey. Travellers can compare confirmed paths by effort—not only fare—using an explainable Comfort Score, visible transitions, a route map and saved preferences.

05

What works today, and what is still mocked?

The end-to-end experience, segmentation logic, traveller-aware filtering, Comfort Score, saved presets, map, checkout handoff and downloadable ticket work in the prototype. Live inventory, reservation locking, payment and official ticket issuance currently use representative data or simulated integrations.

06

How could the idea work safely at a larger scale?

Use authorised railway APIs, revalidate every segment before payment and reserve every leg atomically—or charge nothing. Minimise and encrypt personal data, audit ranking decisions, monitor availability and keep RailSetu clearly labelled as a planner until official booking integration is approved.

Under the hood

The stack behind RailSetu.

Every language, framework, library and production tool currently used to build and run the experience.

  • LanguageTypeScript5.9
  • LanguageJavaScriptES2024
  • LanguageTSX + JSX
  • LanguageCSS
  • FrameworkReact19.2
  • FrameworkNext.js16.2
  • FrameworkVinext1.0 beta
  • LibraryReact DOM19.2
  • LibraryQRCode React4.2
  • LibraryPaper Design Shaders0.0.80
  • LibraryReact Server DOM19.2
  • LibraryCloudflare Workers Types2026.05
  • LibraryReact Types19.2
  • LibraryNode Types22.19
  • ToolVite8.0
  • ToolTailwind CSS4.2
  • ToolTailwind PostCSS4.2
  • ToolVite React plugin6.0
  • ToolVite RSC plugin0.5
  • ToolCloudflare Vite plugin1.37
  • ToolOpenAI Sites plugin0.1+
  • ToolTypeScript compiler
  • ToolESLint9.39
  • ToolNext.js ESLint config16.2
  • ToolLightning CSS1.33
  • ToolWrangler4.92
  • Toolnpm
  • ToolGit
  • ToolOpenAI Codex
  • PlatformNode.js22+
  • PlatformCloudflare Workers
  • PlatformOpenAI Sites

Move your pointer over the stack to pause it.

Made with travellers

See something we can improve?

Tell us what felt useful, confusing, or missing. Short and honest is perfect.