VITRide: Exploring Student Carpooling with Flutter, H3, and Gemma

In university settings, carpooling demand exists naturally: students at the same school share similar schedules, destinations are concentrated, and departure times overlap. But turning this into a product takes far more than a few map screenshots. Developer @parthlightning submitted a prototype called VITRide in the Hacktoberfest Open Source AI Challenge, aimed at VIT Pune students, building a complete ride-hailing flow with Flutter and outlining a matching roadmap backed by H3 spatial indexing and the Gemma model.

First, a clarification: this is a prototype, not a usable carpooling service. Nearby vehicles are synthesized, ride requests assign a predefined driver after a short delay, and there is no backend, no real-time dispatch, no student identity verification, and no actual ride-share matching yet. Precisely for this reason, its value lies not in being "usable" but in demonstrating a clear technical evolution path: get the user experience working first, then progressively introduce spatial indexing and AI preference parsing.

What the Prototype Covers: From Destination Selection to Ride Booking

VITRide currently demonstrates a complete main ride flow: students select a destination, preview the route, compare vehicle types and estimated fares, see nearby vehicles on the map, and then initiate a ride request. The project's self-description is clear about its positioning—focus first on "how students interact with the app" rather than getting bogged down in backend complexity too early.

Specific features include several parts: a vector map custom-drawn in Flutter, overlaying synthesized vehicles and route visualization; route previews generated after destination selection, with distance and duration estimates; vehicle type selection and fare estimation; a simulated ride-booking and driver-assignment flow; and a pure Dart H3-style spatial index with an optional map grid visualization overlay. There are also prototype-level safety status and device audit interfaces.

Worth noting is the nature of the data in the project. Route geometry, vehicle positions, traffic segments, fares, surge pricing, and driver information are all illustrative data, and the README warns they should not be treated as real information. This is entirely reasonable for a prototype, but it also means any discussion of "matching efficiency" currently stays at the architectural level.

H3 Spatial Indexing: Laying the Foundation for "Nearby"

The first technical problem in carpooling matching is how to efficiently find geographically nearby candidates. The traditional approach is latitude-longitude range queries, but doing radius searches on a spherical surface easily runs into boundary and precision issues. H3 is Uber's open-source hierarchical hexagonal geospatial indexing system, which divides the Earth's surface into hexagonal grids, each cell with a unique index, and supports multiple resolution levels.

VITRide implements a pure Dart H3-style spatial layer as a starting point for finding geographically proximate candidates. The developer's approach: first use spatial indexing to converge the vague concept of "nearby" into a computable candidate set, then evaluate route overlap, time compatibility, and remaining seats on top of that.

This layered design is deliberate. Spatial indexing solves the candidate set size problem, while matching quality depends on subsequent rules. Separating the two means each layer can be independently tested and replaced, without turning the entire dispatch logic into a black box when AI is introduced.

H3 was open-sourced by Uber in 2018, and its core design projects the Earth's surface onto an icosahedron and then recursively subdivides it into a hexagonal grid. Each hexagonal cell is uniquely identified by a 64-bit integer index that encodes the resolution level and cell position. H3 provides 16 resolution levels from 0 to 15, with the coarsest level having a cell area of about 4.25 million square kilometers and the finest about 0.9 square meters, allowing developers to choose granularity based on business needs. Compared to rectangular latitude-longitude queries, hexagonal grids have more uniform neighborhood relationships—each cell has 6 adjacent cells, avoiding the inconsistent distances of "corner neighbors" in square grids. H3 also provides operations like kRing (finding all cells within k rings of a given cell) and polyfill (filling an arbitrary polygon with hexagons), making it ideal for queries like "find candidates within a certain range of a point."

Gemma's Role: Parsing Preferences, Not Deciding Assignments

The most discussion-worthy part of the project is how Gemma is positioned. The developer's example is concrete: a student can input in natural language, "I need to get to school around 8:30 AM, and I can accept a small detour if it reduces the cost." A Gemma-powered component can parse this sentence and convert it into structured preferences—expected departure time window, acceptable detour range, and so on.

But the key is the boundary: the actual decisions about matching and dispatch remain with a deterministic service independent of the language model, evaluating candidates by explicit rules such as location, route overlap, time, and seats. Gemma's role is to convert vague human expressions into machine-usable parameters, and to explain to students "why this ride fits your preferences."

This approach is effectively a pragmatic stance on AI's role in critical systems. Language models excel at understanding intent and generating explanations, but are unsuitable for dispatch decisions that need to be reproducible and testable. Separating the two leverages AI's flexibility while preserving the dispatch system's auditability. For scenarios like student carpooling that involve personal safety, this trade-off is far more prudent than "letting the large model handle all dispatch."

Gemma is a family of open-weight language models released by Google DeepMind in 2024, available in parameter sizes such as 2B and 7B, with tuned versions for instruction-following and dialogue. Unlike hosted models accessed via API, open weights mean developers can download model files and run inference locally or on their own infrastructure. Gemma is built on technology related to Gemini but scaled down to fit consumer-grade hardware. In VITRide's vision, such models are well-suited for the task of "converting a natural language sentence into structured fields"—for example, parsing "get to school by 8:30 AM, okay with a small detour to save money" into a departure time window and maximum detour ratio. Such tasks have low latency and determinism requirements, and errors are caught by the rule layer, making this a relatively safe landing spot for language models in a carpooling system.

Open-Weight Models and Privacy Trade-offs

Student carpooling inherently involves sensitive information: travel routes, schedules, and real-time location. The developer mentions that open-weight models like Gemma offer the possibility of exploring local inference—where device conditions allow, there is no need to send all preference data to a hosted AI service, giving more control over how data is processed and where it goes.

A sober note is needed here: local inference is a future direction for the project, not an existing feature. The developer himself emphasizes that open-weight models alone do not guarantee privacy or security. Real deployment also requires appropriate user consent, location data minimization, secure storage, student identity verification, and thorough testing of the matching system. These engineering and compliance efforts often determine whether a product can launch far more than model selection does.

Open-weight and open-source are often conflated in the AI field but mean different things: open-weight means model parameters are publicly downloadable, while training data, training code, and the full reproduction pipeline may not be public. For privacy discussions, the key difference is where inference happens—hosted APIs mean user input leaves the device, while local inference can keep data on the device. But the feasibility of local inference is limited by model size, memory, and power consumption; 2B-level models can run on phones, while larger models require edge servers or fallback plans. Moreover, local inference only addresses "whether data leaves the device"; it does not solve the problem of the model itself potentially memorizing or leaking training data, nor does it replace fundamental security measures like transport encryption, access control, and data minimization.

Next Steps: From Simulated Dispatch to Real Backend

According to the developer's plan, the next phase is to replace simulated assignment with a backend that manages students, available trips, routes, departure times, and seat counts. On this foundation, a deterministic matching service can evaluate location proximity, route overlap, time compatibility, and remaining seats.

This roadmap's pacing deserves recognition: validate the interaction first, then add spatial indexing, then design deterministic matching, and only then let AI parse preferences. Each step has clear inputs and outputs and can be independently verified. For developers wanting to try similar projects, VITRide provides a reference layered skeleton—though it is still a considerable distance from a production-grade service.

The project's first users were the developer's friends at university, who found the idea practical and offered many suggestions to make the app more accessible. From an open-source collaboration perspective, this may be exactly the right starting point for such a prototype: validate demand within a small circle first, then progressively fill in engineering and security gaps.

One-line Summary

VITRide is a Flutter carpooling prototype demonstrating a layered matching roadmap with H3 spatial indexing and Gemma preference parsing.

Paragraph Summary

VITRide is a student carpooling prototype submitted by developer @parthlightning in the Hacktoberfest Open Source AI Challenge, aimed at VIT Pune students. Built with Flutter, it implements a complete interaction flow: destination selection, route preview, vehicle type and fare comparison, map vehicle display, and simulated ride booking. The project is explicitly a prototype rather than a usable service: vehicles are synthesized, drivers predefined, and there is no backend or real dispatch. Its technical value lies in demonstrating a layered evolution path—a pure Dart H3-style spatial index filters geographically proximate candidates, a deterministic rule service evaluates route overlap, time compatibility, and seats to complete dispatch, while Gemma is only responsible for parsing natural language preferences into structured parameters and generating explanations. The developer emphasizes that open-weight models offer the possibility of local inference, but local inference remains a future direction and the model itself does not guarantee privacy or security. Next steps include introducing a backend and replacing simulated assignment with a deterministic matching service.