Routinerary

Inspiration We wanted to solve a problem Google Maps quietly ignores: it assumes you have data, an app, and time to search. That assumption breaks exactly when people need help most: no signal, no data plan, an older phone, or a dead battery at a bus stop. We also noticed a concrete gap. Even the MTA, the highest-ridership transit system in the country, offers SMS for buses but nothing for its subway.

What it does

Routinerary is a text-message-based daily assistant. Text a keyword, get an answer, no app, no login beyond a phone number:

WEATHER [place]: current forecast and an outfit suggestion, for any location Any place name: matched to the nearest real transit stop, with live arrivals when available SAVE [name]: save a commute for instant recall later HELP, PAUSE, START: full user control over messaging

It runs on two live channels sharing one decision engine: SMS via Twilio, and iMessage via Photon/Spectrum, proving the architecture is genuinely provider-agnostic, not tied to one vendor.

How we built it

Node.js/Express backend, with a shared handleIncoming() function that both messaging providers call. Each provider is a thin adapter translating its own message format in and out. Weather comes from OpenWeatherMap and Open-Meteo, with graceful fallback. Transit stop-matching uses the Haversine formula against real GTFS static data from Binghamton's BC Transit. Live arrivals parse GTFS-Realtime protobuf feeds where available, with an honest fallback message when they aren't. Favorites persist in SQLite, scoped per phone number.

Challenges we ran into

The biggest challenge wasn't code, it was infrastructure. US carriers require SMS senders to complete identity verification before sending any custom message, a process that takes 3 to 5 business days regardless of provider (we confirmed this holds true for Twilio, and researched several alternatives). Rather than stall on a blocker outside our control, we diagnosed it precisely, submitted our verification, and built a second live channel (iMessage via Photon) in parallel, so we always had something real to demo. We also hit a real data bug worth mentioning. Matching Google Places results to actual transit stops required correctly parsing a GTFS stops.txt file with non-obvious column ordering, a subtle bug that would have silently broken every distance calculation if left uncaught.

Accomplishments we're proud of

A genuinely working, testable core. Six phases built, each verified independently via direct request simulation before ever touching live delivery. A real accessibility story: this app works for someone with no data plan, on a hackathon-scale free-tier server, without asking anything more of the user than a text message.

What we learned That "no wifi needed" is a real design constraint that shapes every decision, including which messaging provider is even viable. And that provider-agnostic architecture isn't just a nice-to-have. It's what let us keep shipping when one provider (Twilio) hit a genuine, unavoidable delay.

What's next Toll-free SMS verification is already submitted and in review. Beyond that: a proactive daily push (weather and saved commute, delivered automatically each morning, already built as a stretch feature), budget-aware nearby food and attraction suggestions, and expanding transit stop-matching to any GTFS feed, including systems, like NYC's subway, that currently have no SMS option at all.

Built With

• axios
• better-sqlite3
• express.js
• javascript
• node-cron
• node.js
• sdk
• spectrum-ts
• twilio