This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle
What I Built
I built a Flutter-based student ride-sharing prototype that covers the core journey of requesting a ride. Students can choose a destination, preview a route, compare ride categories and estimated fares, view nearby vehicles on a map, and request a ride.
The goal is to explore how spatial indexing and AI-assisted preferences could make student ride-sharing more practical. The project includes an H3-based spatial layer as a starting point for finding geographically nearby candidates.
The app is currently a prototype, not a live ride-sharing service. Nearby vehicles are synthetic, ride requests use a predefined driver assignment after a short delay, and there is no backend, real-time driver dispatch, student verification, or shared-ride matching yet.
Demo
Code
Student Ride-Sharing Prototype
A Flutter prototype exploring a student ride-sharing experience. It demonstrates a map-based trip flow: choose a destination, preview a route, compare ride categories and estimated fares, and request a ride.
This is a completed prototype, not a live ride service. Nearby vehicles are synthetic, and ride requests use a simulated dispatch flow that assigns a predefined driver after a short delay. The app has no backend, live driver dispatch, student verification, or shared-ride matching.
Features
- Custom Flutter vector map with synthetic nearby vehicles and route visualization.
- Destination selection and generated route previews with distance and duration estimates.
- Ride category selection and fare estimates.
- A simulated ride-request and driver-assignment flow.
- A pure Dart H3-style spatial indexing implementation, with an optional map grid visualization.
- Prototype security-status and device-audit UI.
The route geometry, vehicle positions, traffic segments, fares, surge values, and driver details are illustrative prototype data. They should not…
How I Built It
I focused on building the ride flow first, so the prototype demonstrates how a student would interact with a ride-sharing application before introducing the complexity of a live backend.
The app brings together destination selection, route visualization, ride-category comparison, fare estimation, nearby vehicle markers, and ride requests. The spatial indexing layer provides a foundation for organizing geographic data and identifying potential candidates efficiently.
The next development phase is to replace simulated assignments with a backend that manages students, available rides, routes, departure times, and seat availability. A deterministic matching service could then evaluate location proximity, route overlap, timing compatibility, and available seats.
Where Does Gemma Fit?
For example, a student could enter a request in natural language:
“I need a ride to college around 8:30 AM, and I can take a small detour if it reduces the cost.”
A Gemma-powered component could interpret this request and convert it into structured preferences, such as the desired departure window and acceptable detour. A separate matching service would then evaluate candidate rides against explicit rules for location, route overlap, timing, and seat availability.
Gemma could also explain why a ride is compatible with a student's preferences. However, the actual matching and dispatch decisions should remain deterministic, testable, and independent of the language model.
This separation would make AI useful without giving it unchecked control over ride assignments.
Why Does Open Innovation Matter?
Student ride-sharing involves potentially sensitive information, including travel routes, schedules, and location data. Open-weight models such as Gemma offer an opportunity to explore local inference, where supported, instead of relying entirely on a hosted AI service.
This could provide greater control over how ride preferences are processed and where that information is sent. However, local inference is a future direction for this project, not a feature of the current prototype.
A real deployment would also require appropriate consent, location-data minimization, secure storage, student verification, and thorough testing of the matching system. Using an open-weight model alone does not guarantee privacy or security.
My First User
My first user being my friends from college who found the idea highly useful and recommended a lot of things in order to make the application helpful for everyone.
Solo submission by @parthlightning
Top comments (0)