RideHou

RideHou: prototype interface and core workflow.
RideHou: prototype interface and core workflow.
RideHou: prototype interface and core workflow.
RideHou current live app interface (captured 2026-09-27 19:40 UTC).

Inspiration

The challenge focused on young people who lack a reliable way to get to work. RideHou explores a recurring-commute model instead of asking a rider to publish an exact destination or a driver to create a one-off taxi service.

What it does

People can browse broad-zone offers by day, shift time, seats, and contribution cap. Drivers can describe a commute they already make, riders ages 18–24 can request a seat, and riders ages 16–17 have only a guardian-supported interest path that is never accepted as a ride match. Exact addresses, employer names, phone numbers, payments, and contact exchange stay out of the public flow.

How I built it

The prototype uses Vite and vanilla JavaScript, an Express and TypeScript API, PostgreSQL with Drizzle ORM, Google identity and server sessions for authenticated actions, and coarse public views that redact contact details. Source links point to METRO Vanpool and Commute Solutions resources.

Challenges

This is a safety-sensitive problem involving minors, transportation, and trust. The product encodes age and guardian boundaries, keeps seeded records visibly fictional, and avoids presenting self-attestation as screening, background checks, insurance, or safety verification.

Accomplishments

RideHou delivers a focused discovery and publishing flow, broad-zone privacy rules, minor-specific boundaries, recurring schedule fields, and a working public demo and pitch. It makes the liability boundary part of the product contract.

What I learned

A useful prototype can clarify what a responsible pilot must verify. Coarse discovery lowers exposure, but it does not replace safeguarding, screening, insurance, or a real operating partner.

What's next

A first pilot would need a responsible youth-serving or transportation partner, guardian and driver protocols, screening, insurance, escalation, and a carefully limited geography. Those controls should be designed before exchanging contact details or accepting a ride request.