Problem Statement
In a community of 4,000 students living just floors apart, we still handle every mundane errand alone simply because we have no way of knowing when our neighbours need a hand, no structured mechanism to match real-time needs with nearby supply of help.
The density for spontaneous mutual help is almost unmatched anywhere in Singapore. Students will absolutely pick up lunch for a neighbour, help carry boxes for $5, or be a study partner if someone just asks. But the demand is invisible. There's no mechanism to surface it and no way to trust a stranger responding to it.
Collectively, these micro-needs happen hundreds of times a week across the campus and almost all of them go unmet, despite countless students being willing to help. The problem is mundane, and that's exactly what makes it universal.
We built Ripple to change that. And we believe the solution is to build a new kind of community infrastructure.
Our Solution
Ripple is a mobile peer-request platform for NUS UTown residents. Post a Quest: a small request, errand, or even a social hangout, and the right neighbour finds it, accepts it, completes it, and earns a reputation doing so. Users have to sign up using their NUS email addresses, and receive an OTP for email verification.
1. Solving Invisible Demand
Ripple replaces high-noise group chats with structured "Quests" that remain visible on the map and feed until fulfilled. Our algorithm ranks these tasks based on your habits, proximity, and time-of-day relevance, ensuring the right person sees the right request. Semantic search further closes the gap, allowing students to find help based on intent rather than specific keywords.
2. Surfacing Invisible Supply
Our Broadcast feature allows students to share their intended routes. The system reverse-matches these trips with active needs and can even prompt neighbours to post quests if a helper is heading their way. GPS-aware mapping reinforces this by highlighting tasks directly on your walking path, turning a routine commute into a fulfilment opportunity.
3. Engineering Accountable Trust
Trust is built on verified NUS identities, ensuring every interaction is tied to a real student rather than an anonymous username. We use a composite Trust Score that tracks completion rates and response times, alongside "Tiers" that gate sensitive tasks like food delivery to proven users. Features like contactless photo proof and a rigorous strike system provide the concrete accountability necessary for a safe peer-to-peer network.
How It Works
The Ripple Feature Suite
| Stage | Feature | The "Ripple" Impact |
|---|---|---|
| Post | Smart Autocomplete | Instant, standardized location tagging for every campus landmark. |
| Flash Quests | One-tap urgent mode to highlight time-sensitive emergencies. | |
| Dynamic Quest Types | Switch between solo errands, social hangouts, or "Crew" group tasks. | |
| Discover | Live Clustered Map | A "Living Map" that bundles nearby requests into tidy, interactive bubbles. |
| Proximity Feed | Intelligent ranking that sorts the feed by your live GPS distance. | |
| Route Broadcasts | Supply-side alerts: "I'm heading out anyway, who needs a hand?" | |
| Connect | Internal Chat Shell | Secure, in-app coordination without sharing personal Telegram or phone handles. |
| GPS Pings | Share your live location as a mini-map preview directly in the chat. | |
| Fly-To Navigation | Tap a shared location to snap your main map focus to your peer’s spot. | |
| Complete | Visual Proof | Mandatory drop-off photos stored securely as "evidence" of fulfillment. |
| Trust Tiers | Progression from Wanderer to Pioneer based on verifiable reliability. | |
| Composite Scoring | A game-proof rating system factoring in speed, strikes, and consistency. |
Other Features:
- Hybrid Map Engine: Custom-built to toggle between Web (Pigeon Maps) and Mobile (Native Maps) using a single logic layer.
- Mission-Aligned Math: A feed algorithm that is customised for each and every user.
- Privacy-First Architecture: Uses Supabase Row Level Security (RLS) to ensure private messages stay private, even at scale.
- Zero-Latency Sync: Real-time WebSocket integration so new pins appear on the map the second they are posted.
How we built it
Frontend: Universal Geospatial Interface
- Core Framework:
React Native(Expo SDK 55) withexpo-routerfor unified tab-based navigation and coordinate-based deep linking. - Hybrid Map Engine: A specialised dual-provider implementation using Pigeon Maps and react-native-maps. A LocationMarker interface with two separate
MapEngineimplementations (.native.tsx/.web.tsx) sharing the same prop contract, the rest of the app is map-engine-agnostic. - Design System: NativeWind v4 (Tailwind CSS) integrated with a custom Glassmorphism engine utilising CSS
backdrop-filter(Web) andexpo-blur(Native) for a translucent, futuristic aesthetic.
Backend: Real-time Infrastructure
- Database: Supabase (PostgreSQL) utilising geospatial data types for precision coordinate storage and strict Row Level Security (RLS) to ensure data isolation.
- Real-time Engine: Supabase Realtime (WebSockets) powering a "Living Map" where quest markers and in-app chat messages sync instantly across all clients.
- Object Storage: Supabase Storage with automated bucket pathing for encrypted chat media and high-resolution drop-off proof photos.
Feed personalisation algorithm: client-side weighted scoring
We implemented a client-side weighted scoring engine in pure TypeScript to personalise the community feed without heavy backend overhead. Quests are ranked using five dynamic weights: category affinity (history + skills), location (RC proximity + diversity), urgency, recency, and reward appeal. Critically, the weights shift based on the quest category.
Trust system: Composite score from completion rate (30%), average rating (40%), response time (10%), and strike penalty (20%). Three tiers computed atomically by a PostgreSQL function after every rating. The strike system escalates: 2 strikes → temporary suspension from posting; 3 strikes → case escalated to NUS / RC management. Every strike is tied to a verified NUS student identity, which makes it a real deterrent.
What makes Ripple different and special
The obvious comparison is a gig marketplace, like Grab. The comparison breaks down for three reasons:
Piggybacking, not hiring. Apps like Grab hire someone to make a dedicated trip. Ripple matches your request to someone who's already heading there. The marginal cost to them is near-zero, which is why $2–3 feels fair. This only works at hyperlocal density, and the AI matching is built specifically around it!
Supply speaks first. Every marketplace waits for demand to post. Broadcasts let supply broadcast availability before anyone asks too! This is a reverse quest: the supply advertises itself, and the demand responds. No mainstream task marketplace does this because at city scale the odds of geographic overlap are too low. At the density of Residential Colleges, this is a super natural interaction.
Tasks and socialising in one system. No gig app handles "looking for a study buddy for CS2040S tonight." Ripple is the only platform that bridges transactional micro-favours and social activity matching in the same system, because in a residential community, those two categories are tightly intertwined.
Impact
Ripple allows students to reclaim precious personal time by outsourcing repetitive errands to peers who are already on the move. Instead of interrupting a much-needed rest or a hobby to handle a quick snack run or a trip to the printer, residents can protect their personal downtime. This small shift in coordination provides significant breathing room, helping students better balance their high-pressure schedules with personal wellbeing.
The app actively breaks down the walls between individual Residential Colleges by encouraging inter-college help and social quests. A student in Acacia might pick up a package for someone in Tembusu, turning a simple favour into an organic introduction. This transforms RCs into a close-knit community where students are actually aware of and supportive of those living outside their immediate friend groups.
Furthermore, new residents and exchange students no longer have to feel lost or isolated if they haven't built a circle yet; they have instant access to a verified network of neighbours. This accelerates the feeling of belonging, ensuring every resident feels safe and supported from their very first day on campus.
Feasibility
Zero Infrastructure Costs: Ripple requires no physical installation on campus. It leverages the hardware students already carry (smartphones) and the existing campus infrastructure.
Hyper-Local Efficiency: RCs are the perfect audience for Ripple. Because students live, eat, and study within a 500-meter radius, the "piggybacking" model is highly effective, and students can swiftly receive help from their nearby neighbours.
Self-Regulating Safety: Real-world implementation is made realistic through our Automated Trust Logic. The system uses "Strikes" and "Tier-Gating" to self-police. Every user has to sign up with their NUS email, and it requires OTP authentication. This helps to ensure the platform remains safe, while escalating repeated reports and violations to higher-ups.
Universal Accessibility: Our Hybrid Map Engine ensures that whether a student is on a high-end iPhone or a browser on their laptop, they have full access to the community’s needs, making it a truly inclusive tool for all residents.
Challenges we ran into
Trust that's hard to game. A first-pass trust system gated purely on star ratings is trivially abusable since one friend can boost your score overnight, we rebuilt it as a composite weighted formula: completion rate, response time, average rating, and strike count, all recalculated atomically in a single SQL function after each rating. We also gated access to certain types of quests like food quests based on reputation, ensuring the safety of our users.
Cross-platform maps with identical props. react-native-maps and pigeon-maps have completely different APIs. We abstracted quest location data into a shared
LocationMarkerinterface and wrote twoMapEngineimplementations that consume identical props. The rest of the app calls one component and gets the right map for the platform.Real-time without race conditions. Supabase Realtime subscriptions refetches running simultaneously caused duplicate messages in chat. Fixed by making the Realtime stream the single source of truth for in-session chat, with the initial fetch only seeding the array, then subscriptions handle everything after mount.
What we learned
Personalisation doesn't always require "Big AI." While we started with heavy AI concepts, we learned that thoughtful heuristics are often faster and more effective than massive ML models. By building our weighted scoring algorithm in pure TypeScript, we achieved a "learning" feed that feels smart and responsive without the latency or cost of server-side inference. We realised that prioritising efficiency and compute is more valuable than simple engagement-hacking.
Trust is a product, not a feature. Every design decision either feeds the trust loop or undermines it. We learned to treat the reputation system as load-bearing infrastructure, not a leaderboard gimmick. The strike system, tier gating, and composite scoring are why the platform can work between strangers.
RLS forces you to think about security upfront. Supabase's Row Level Security was initially painful to configure correctly. But it produced a genuinely secure permission model from day one and the discipline of thinking in policies rather than runtime checks made the whole codebase more coherent.
What's next for Ripple
Immediate:
- In-app PayNow / Stripe Connect for in-app payments, eliminating the awkward "please PayNow me" moment post-completion and creating a verifiable transaction log that solves the non-payment dispute problem entirely.
- Full NUS Student Pass matric validation for complete identity assurance (currently just NUS email domain gating + OTP).
- iOS/Android App Store release via EAS Build.
- RC admin dashboard, deans and RAs see anonymised quest activity, spot community trends, and push official flash quest announcements.
Near-term:
- Full AI piggyback matching: 3-step scoring pipeline: geohash proximity filter, pgvector embedding similarity, GPT-4o contextual re-ranking of top candidates, triggered by Supabase webhook on quest insert. Currently, route offer matching handles the supply-side; this extends proactive matching to all users based on real-time location and movement vectors.
- Geospatial Intelligence: Client-side Marker Clustering algorithm to optimise high-density pin areas and real-time proximity sorting to prioritise tasks based on live GPS data.
Scalability:
- Can easily expand to other NUS residences (Halls, PGP, UTown Graduate Residences), same architecture but with new location datasets, and zero physical infrastructure costs.
- University-agnostic white-label: any dense residential campus globally where the goodwill-to-infrastructure gap exists can implement our app.
Built With
- expo-location
- expo-router
- expo.io
- lucide-react-native
- openai-gpt-4
- pigeon-maps
- postgresql
- react-native
- react-native-maps
- supabase
- supabase-auth
- supabase-realtime
- supabase-storage
- tailwindcss
- typescript
Log in or sign up for Devpost to join the conversation.