OnRoute

Inspiration

Every NED student who rides the shuttle knows the moment: you reach your stop and the point has already left, or it's late and nobody knows by how much. The university publishes a route PDF, but it tells you nothing once the plan breaks. You end up texting five group chats, guessing, and then paying for a Bykea, inDrive or rickshaw you may not have needed.

We didn't want another tracking app that pretends to have live GPS. NED has no public shuttle feed, and we weren't going to depend on admin cooperation or fake one. We asked a smaller question: when your shuttle point fails you, what's the best realistic move right now, and how sure can we honestly be about it?

What it does

OnRoute is a commute decision assistant for NED students. You sign up with your point number and usual stop, then tell the app where you are, your arrival deadline, and whether you care most about speed, cost, or a balance. It returns ranked option cards, each with steps, an expected arrival, a cost, and a confidence badge.

It handles three scenarios:

My point already left my stop. It checks every later stop on your route and shows where you can still catch the point, based on your own ride quote (price and minutes) or known walking times.
Where is my point right now? Students report with one tap: "Point seen here", "Point departed", "Point not here". A fresh report from an earlier stop upstream gives an estimated arrival range for your stop. Stale reports are greyed out, conflicting reports are flagged, and reports from stops after yours are ignored.
Hop on a nearby point. Where two routes share a physical stop (for example Sakhi Hassan, shared by several routes), the app suggests switching points.

Nothing is dressed up as more certain than it is. Every result carries a label: Scheduled, Reported, Estimated, Unknown, Stale, Conflicting, or DEMO DATA. An "Explain these options" button puts the results in plain language, and if the AI is unavailable the app falls back to a rule-based summary.

How we built it

Data first. We transcribed the 2024–25 NEDUET shuttle PDF and turned it into a structured routes.json covering 16 morning routes, with a shared-stop index for transfers. Stop-name variants (Malir Halt/Hault, Nursary/Nursery and similar) were merged and then checked by hand.
A deterministic logic engine. Feasibility, ranking, report freshness, and confidence labels are plain code with tests. There's no AI in the decision path, so the app can't hallucinate a route or a time.
AI only explains. A Supabase Edge Function sends the engine's JSON output to Claude with strict instructions to use only the data given and say "unknown" when something is missing. The API key lives only in Supabase secrets, never in client code.
Stack. A Vite web app, with Supabase for auth, the reports table, and the Edge Function, built in Devmarketplace.
Process. We wrote a team execution brief, a spec, an AGENTS.md with hard rules for AI coding agents, a SKILLS.md of task playbooks, and a numbered prompt sequence. Each builder prompt named exactly one file to touch and forbade inventing data, which kept the AI builder in line.

Challenges we ran into

The route PDF has no per-stop times. It gives only the first-stop departure and the stop order. The "point already left" and upstream ETA features both need per-stop timing, so we couldn't compute them from the source. We labelled later-stop times as DEMO DATA or Estimated, and the engine returns Unknown rather than inventing a default.
The AI builder hallucinated badly. It invented stops, rewrote files we hadn't mentioned, and mixed logic into the UI. We fixed this with narrow, single-file prompts, a grounding check before the real work, and a rule that logic and UI never mix.
No verified walking links. Offering "nearby" transfers between stops we couldn't verify would have meant making them up, so we only support transfers at genuinely shared stops.
Time. With four days and a team juggling classes, we had to cut scope hard and stop adding features ahead of the freeze.

Accomplishments that we're proud of

A product whose main feature is honesty. Every output says how much we actually know.
A decision engine that is fully deterministic and tested, with AI kept to explanation only.
A crowd-sourced report system that works with zero reports and degrades gracefully when reports are stale or conflicting.
Turning a plain PDF into clean structured data for 16 routes.
A repeatable workflow for keeping an AI builder grounded, which we'd reuse on any project.
A deployable app with no secrets in the client.

What we learned

Calling the limits of your data is better than hiding them. Judges and students both trust a "Reported 6 min ago" badge more than a confident fake ETA.
Constrained AI beats clever AI. Letting the model explain results rather than produce them removed almost all the hallucination.
With AI coding tools, the data comes first. Vague prompts get invented stops, and one-file prompts with pasted data get working code.
Planning for fallbacks (no key, no reports, no per-stop times) matters as much as the happy path.

What's next for OnRoute

Collect real per-stop timings by having students who ride each route log minutes between stops, replacing DEMO DATA with verified data.
Cover all 16 routes, plus evening returns.
Add verified walking links between nearby stops to unlock more transfer options.
Make reports more trustworthy with reputation, confirmations from multiple riders, and spam protection.
Add push notifications such as "your point was just seen two stops before yours."
Take it to other campuses with shuttle systems that have the same gap.
If NED ever opens up GPS or official data, plug it in as another input rather than rebuilding.