Inspiration

NYC subway riders do not primarily need another map. They need one trustworthy answer before a real deadline: when do I have to leave so I am not late?

There By started from that narrow decision. Instead of making commuters interpret alerts, arrival boards, and route options, it turns a saved morning commute into one clear leave-by time.

What it does

A rider chooses an origin, destination, arrival deadline, service days, and walking time. There By then presents:

  • one hero leave-by time
  • a usual arrival estimate
  • a worst-case estimate
  • late risk
  • ranked alternatives when another route is safer

The language is deliberately consumer-friendly: “Usually,” “Worst case,” and “Late risk,” not statistical jargon. The product answers when to leave; it is not a general trip planner.

How we built it

The client is an Expo/React Native app with a responsive web experience. A typed FastAPI backend consumes and archives MTA GTFS-Realtime data, evaluates supported line and transfer paths, and applies calibrated uncertainty buffers. Production runs with durable storage, privacy-safe error monitoring, health checks, backups, and observable notification delivery.

Forecast facts remain deterministic code and data artifacts. The AI models did not invent transit facts, station data, or forecast outputs.

What changed during Build Week

There By existed before Build Week as a working predictor and calibration foundation. The eligible work after July 13 turned it into an installable, instrumented external beta:

  • shipped the responsive landing page and beta funnel
  • prepared and distributed the iOS TestFlight beta
  • expanded station coverage and improved the map/station-picker experience
  • hardened the leave-now notification pilot with due-window and duplicate protection
  • added push-delivery observability
  • strengthened production authentication, health checks, monitoring, backup, and recovery tooling

The repository documents the pre-existing foundation separately from the timestamped Build Week additions so judges can evaluate only the new work.

How Codex and GPT-5.6 were used

Codex was the primary engineering environment and produced the vast majority of There By. The original product and forecasting foundation were developed primarily in Codex with GPT-5.5. Claude Code assisted with portions of the early UI and planning, which I am disclosing directly.

During Build Week, Codex desktop with GPT-5.6 Sol drove the eligible extension. It inspected the existing repository, helped make product and architecture decisions, decomposed bounded implementation work through a Sol-to-Luna workflow, ran focused verification, reviewed diffs, and carried the product from a working predictor to a release-ready external beta.

Challenges

The hardest product challenge was translating uncertainty into a decision without pretending the subway is perfectly predictable. The hardest engineering challenge was making the last mile trustworthy: broad station coverage, idempotent notifications, observable delivery outcomes, authenticated production services, and recoverable data.

A second challenge was measurement honesty. Diagnostic “prediction checks” are residual samples, not physical train arrivals, so the product and submission preserve that distinction.

What we learned

A useful prediction is not enough. A commuter product has to make the decision instantly understandable, survive real morning behavior, and explain why its answer deserves trust. Build Week pushed the project beyond model output into onboarding, distribution, reliability, and an auditable collaboration history.

What's next

The beta is now live. Next I am recruiting a small cohort of fixed-schedule NYC commuters, measuring whether they return on real mornings, validating leave-by accuracy and notification timing, and using that evidence before broader launch.

Try it

Built With

Share this project:

Updates