egytrains

[ Context ]

egytrains is a schedules site for Egyptian National Railways. Millions of Egyptians check train times every day; the official channels were slow, heavy, and painful on mobile. I built egytrains as a faster, ad-light alternative — no team, no funding, just a tool I wanted to exist.

A year later it's still running, serving roughly a million unique visitors a month on infrastructure that costs one dollar per month.

[ The brief ]

A million visitors a month on a free public tool sounds great until you do the math. If infra cost scales linearly with traffic, you're paying real money to give away a public good. And if you're on-call 24/7 for other people's commutes while also holding a full-time job, you burn out in a month.

So the whole engineering brief was: how do I make this fast for the user, nearly free to run, and boring to operate — so it survives a year of my attention being elsewhere? The answer turned out to be aggressive simplification: no backend, no database on the hot path, no scraper, no cron. Just static files, a CDN, and a curated dataset.

[ Architecture ]

• ~54,000 static pages. Every lookup the site can answer is pre-rendered at build time: individual station pages (departures and arrivals), station-pair pages (every A → B route), and train/route detail pages (full stop lists and times). A "dynamic search" becomes a static HTML file. No database reads on the request path.
• Hand-curated dataset. ENR doesn't publish a machine-readable feed, so the schedule data is curated by hand and updated only when ENR themselves publishes a new timetable. That sounds unscalable until you realize national train schedules change rarely — and any scraper would have to be rewritten every time the official site does.
• Firebase Hosting for the origin. Free tier plus light overage; the reason the monthly bill lands near zero is that almost no requests ever reach it.
• Cloudflare in front as a caching proxy. Nearly every response is served from the CDN edge, which collapses Firebase egress to a trickle — and incidentally gives the site global latency for free.
• Rebuild on new schedules. When ENR publishes an updated timetable, the site regenerates the full ~54k pages and redeploys. Between schedule changes there is nothing running at all — no cron, no background worker, no live backend.

[ Why $1/month ]

The cost model is the whole trick. Traditional "dynamic" sites pay per request: more visitors, more database queries, more servers, more money. egytrains flips that — the hard work happens once, at build time, and every visitor after that is a static-file lookup served from Cloudflare's edge, where it's effectively free.

Firebase Hosting only sees the cache misses, which are rare. Cloudflare's free tier covers the rest. The only truly fixed cost is the domain itself at roughly $12 / year. Everything else rounds down to about a dollar a month.

[ Results ]

• ~1,000,000 monthly unique visitors, sustained for 12+ months.
• ~54,000 pre-rendered pages covering the full schedule surface — every lookup is a static file.
• $1 / month in infra cost. Domain adds another ~$12 / year.
• Zero incidents in 12+ months. The architecture has no live backend between deploys, so there's nothing to wake me up at 3 a.m. — and nothing has.