Get Home Faster for Less

Hop: Privacy-First Ride-Sharing for NUS Students

Try it now!

Problem Statement

Many NUS students who live far from campus face a difficult trade-off when travelling home: public transport can take well over an hour while private-hire rides during peak periods are often expensive. To reduce cost, students frequently turn to informal Telegram or chat groups to find others to split Grab fares.

While this can save money, coordination is entirely manual: riders must find people going in a similar direction at a compatible time, and matches are typically limited to personal networks or whoever happens to see a message in a large, noisy channel. Worse, making rides work often requires sharing home addresses in semi-public chats with strangers, creating a privacy risk. There is no structured, trustworthy way to coordinate shared rides without exposing sensitive location information broadly or relying on ad-hoc messaging.

Our Solution

Hop is a privacy-first web application designed to automate ride-sharing for NUS students. It securely pools students who are leaving campus around the same time and heading in the same general direction. By automating the matching process, Hop allows students to split fares easily, getting the convenience and speed of a private hire vehicle at a fraction of the cost, without sacrificing their personal data.

Key Features

Feature	Problem It Solves
Credibility Score	Creates long-term accountability. Reliable users are rewarded (e.g., become the booker); unreliable users face consequences (lower score, eventually blocked).
Matching Algorithm	Groups riders intelligently based on distance, time, and route similarity metrics.
Booker Redelegation	Handles real-world edge cases where booking is cheaper on someone else's Grab account, or when the assigned booker does not show up.
In-App Chat	Allows riders to communicate directly on the web app without exposing their phone numbers or personal contact information.
QR Check-in	Prevents no-shows. The booker scans riders at the meeting point; absent riders are removed from the group and penalized.
Payment Proof Screenshots	Eliminates "I already paid" disputes. Riders upload proof, the booker verifies it, and unverified users are blocked from joining new rides.
End-to-end Address Encryption	Addresses are `AES-256-GCM` sealed in the matcher service and `RSA-OAEP` encrypted per-recipient. The main database never sees plaintext addresses.

How It Works (Technical Overview)

System Architecture

Hop is built as a privacy-first rideshare platform with three main parts working together:

Frontend Web App: A Progressive Web App (PWA) built with Next.js. Students can log in, set preferences, submit ride availability, and view group assignments from any device.
Live Backend: Convex acts as the live backend. It manages authentication, stores app data, powers real-time updates, and handles workflows like OTP login and notifications.
Secure Matcher Service: A separate, isolated service that processes sensitive destination information. Because exact addresses are never stored in the main app database, the browser sends destination data directly to the matcher. The matcher keeps only protected references, calculates compatible riders, and only reveals address details when the correct ride conditions are met.

The Matching Pipeline (Privacy-First)

At the heart of Hop is our rule-based matching engine. Instead of exposing addresses in public chats, our pipeline securely processes ride requests through five distinct stages:

Seal: User addresses are geocoded on the client and immediately AES-256-GCM encrypted. The ciphertext is sent to our backend. Convex (our main database) never sees the plaintext addresses.
Score: The isolated Matcher Service calculates a pairwise compatibility score based on: 55% route overlap, 30% proximity, and a 15% time window. Matches are instantly rejected if the detour takes > 12 minutes or if the rider spread is > 8 km.
Group: We use a greedy algorithm, attempting to maximize ride efficiency by trying group sizes of 4 → 3 → 2. Groups are ranked by their average score, then minimum score, then the detour time. Smaller groups are held in the pool until T-36 hours to allow more riders to join.
Lock: At T-3 hours to the ride time, the group is locked and an acknowledgment request is sent. If 2 or more riders accept, the meetup is confirmed. Any unconfirmed slots or leftover riders are reopened to the matching pool.
Reveal: Final destination addresses are packaged into RSA per-recipient envelopes. Riders use their local private keys to decrypt the addresses. This guarantees that each rider decrypts only their own confirmed group's addresses, keeping all other system data entirely private.

Smart Logic Components

Hop does not rely on heavy generative AI models in its core product flow. Instead, its "smart" behavior comes from the operational logic detailed in our pipeline above. The intelligence in the system is focused on optimizing matching decisions for practical ride coordination while mathematically minimizing how much sensitive data is shared.

Built With

Our tech stack was carefully chosen to balance speed, privacy, and real-time reliability:

Languages & Frameworks: Next.js (React), Progressive Web App (PWA) configuration, Express (Node.js), and TypeScript.
Backend, Database & Cloud: Convex for real-time state and database management; Vercel for frontend hosting.
Security & Cryptography: AES-256-GCM for symmetric authenticated encryption, RSA-OAEP for asymmetric per-recipient encryption, and custom NUS Email Gating for authorization.
APIs & Integrations: OneMap API for precise local geocoding and routing; Resend for OTP email delivery.
Architecture & DevTools: A monorepo architecture managed by pnpm, with a shared types package ensuring data consistency across services. We use Vitest for automated testing and Biome for code quality and formatting.

Impact & Feasibility

Impact

Solves a Daily Pain Point: Addresses a highly practical, frequent problem faced by the student body.
Saves Time & Money: Drastically reduces costs compared to solo private rides while cutting down travel times associated with public transit.
Enhances Safety & Trust: Creates a safer, closed-loop environment compared to public Telegram groups. It eliminates coordination overhead and fosters a trust ecosystem where reliable behavior is rewarded.

Feasibility

Asset-Light: Highly feasible as the app acts purely as a secure coordination layer—it does not require supplying actual vehicles.
Production-Grade Infrastructure: Built on reliable tech like Convex, Vercel, and the OneMap API.
Frictionless Adoption: Being a PWA means no app store approval is needed; it works instantly on any phone via a browser.
Verified User Base: NUS email gating ensures only verified, active students can participate.
Localized Optimization: Specifically designed for Singapore, utilizing the OneMap API for accurate local geocoding and routing.
Proven Concept: The current prototype already successfully handles the full trip lifecycle end-to-end. Unified shared types via monorepo architecture ensure stable scaling.
Highly Scalable: Expanding this solution to other residential communities or universities (e.g., NTU, SMU) requires zero fundamental architecture changes. It only requires updating the authorized email domain logic and localized map bounds.