Coordinated airport rides for university students, over the holidays.
Post your student's flight, get matched with families on the same or nearby flights, form a ride group, and split the cost of ground transport — simpler, cheaper, and safer.
A shared airport-ride board for a university community, scoped to each holiday break.
Add your student's flight — including multi-leg connections. The app coordinates around the university-side airport.
See other students who share a flight segment (same airline, flight number, and date) — useful even if you're taking a shuttle rather than forming a group.
A group lead sets the transport company, pickup time, and rules. Other families request to join.
Cost auto-splits by rider count with tiered pricing — every rider who joins lowers everyone's share.
Notifications for join requests, approvals, bookings, price changes, and timing alerts.
Each university and region runs as its own independent deployment — no shared database, no cross-campus data.
From sign-in to a booked ride.
The app actively prevents unsafe or nonsensical rides — not just records them.
| Guardrail | What it prevents |
|---|---|
| Airport & direction match | You can't join a ride group for a different airport or travel direction than your flight — checked before anything else. |
| Ride-window timing (two-tier) | A pickup moderately far from the flight warns you and asks you to confirm; an extreme gap is blocked outright. |
| Holiday-window guard | Flights must fall within the selected holiday's travel window. |
| Contact-available to ride | Before joining or creating a group you choose how to be reached — phone, email, or both — and that contact must be on file, so coordination is possible. |
| One active group per flight | A student can't be double-booked across conflicting ride groups for the same flight. |
| Conflict detection | Overlapping rides for the same student are flagged to the parent and the group lead. |
Handling students' and parents' contact details responsibly is a first-class design goal, not an afterthought.
Phone numbers and student email addresses are AES-256 encrypted at rest — never stored in plaintext.
Per group, you decide how you and your student can be reached — phone, email, or both. Only that chosen contact is shared, and only with approved members of the same ride group.
Across the app, families are shown as a first name plus a last initial — enough to recognize each other, without publishing full names to the whole community.
An "I'm interested" option lets you ask a group lead to reach out first — sharing only the contact you choose, without joining or exposing anything to other members.
The per-group copies of both phone and email are erased when a ride completes (or when a member leaves). Only a masked fragment (phone last-4, masked email) is retained for audit.
Persistent contact details are automatically scrubbed after a prolonged period of inactivity, so data isn't kept longer than it's useful.
Google sign-in plus email one-time-codes, backed by secure HTTP-only session cookies with hashed tokens — no passwords to leak.
Access is re-checked on every request, so a deactivated account is locked out immediately — even mid-session.
Every create, join, approval, booking, and data-scrub action is recorded in an audit log.
All input is schema-validated; every database query is parameterized to prevent SQL injection.
Per-IP rate limiting on auth and API endpoints, with anti-harvesting responses on the sign-in flow.
Each university/region is a separate application and database — there is no shared multi-tenant data store.