Wheely Mammoth

Logo

Inspiration

We built Wheely Mammoth as a rideshare app for college students, aimed specifically at creating a more community-oriented, campus-friendly alternative to standard ride-share services. The inspiration came from noticing that on-campus transport often lacks flexibility or feels disconnected from student needs (timing, cost, scheduling, campus zones). We wanted to match drivers (who might have empty seats on trips) with students needing rides — harnessing the campus network and college student trust.

What it does

Allows drivers (students with cars) to post rides – indicating origin/destination, time, maybe seats available.
Allows students/passengers to request rides from those posted offers.
The system matches posted rides to requests, ideally allowing efficient fills and campus-specific routing.
Students are able to use their school login to verify that they are affiliated with the college.
Uses location sharing and real-time price updates through AI to suggest pricing.

How we built it

Project was done in Java and HTML using Gradle.
We started with a mind-map (in the repo) to outline user flows, roles (driver vs passenger), ride posting, request matching, UI screens, data models.
Then we built the backend logic (DemoApplication.java) as a proof-of-concept for ride posting and request handling.
UI/branding assets (pngs) were created and included to visualise the concept.
We chose a simple architecture to enable rapid development for a hackathon environment (likely 24-48 hours) so we kept to core features (post ride, request ride, match) and deferred more advanced features (payments, ratings, campus map integration) for future.
We used GitHub to manage code, demo folder, images, readme and maintained one branch main.

Challenges we ran into

Time constraint: Given this was built for a hackathon (Hack the Herd F25) environment, we had limited time to design, implement, and test.
Scope creep: With many possible features (payments, user ratings, campus geolocation, ride-sharing algorithms) we had to decide what to include now vs defer.
Matching logic: Ensuring ride postings and requests align (time, origin, destination, seats) can be complex; designing a simple but effective matching algorithm was a challenge.
Campus specific constraints: Dealing with campus pickup/drop-off zones, student trust/verification, maybe UI/UX for mobile vs web.
Integration/UX polish: Because of the short timeline we may have had to deploy a simplistic UI or skip mobile native.
Data persistence: For a hackathon prototype we may have used in-memory or simple storage rather than full scalable backend.

Accomplishments that we’re proud of

Built a working prototype of the core concept: drivers can post, riders can request, matching flow is implemented (DemoApplication.java).
Successfully aligned the prototype with the initial mind-map, which shows strong planning -> execution.
Delivered a visually coherent package including branding (pngs) and architecture within the hackathon timeframe.
Created a solution targeted specifically at the student rideshare niche (campus context) rather than generic rideshare — that niche-focus is often overlooked.
Demonstrated feasibility and potential for real-world application (campus rideshare) rather than just a “cool hack”.

What we learned

Narrowing scope is vital: it’s better to build a few features well than many features poorly, especially in a fast-paced hackathon.
Clear user-role definition (driver vs passenger) helps keep UX simple and makes backend logic clearer.
Visual assets and branding matter even for prototypes — helps make the product feel “real” and compelling to judges or future stakeholders.
Matching rideshare logistics (time, seats, origin/destination) are non-trivial even in “simple” form; designing the data models and flow early (mind-map) is very helpful.
Using a planning artefact (mind-map) pays off: you can see dependencies, flows, user journeys before coding.
We learned how to collaborate under pressure, pick the right tech (Java here), and deliver a complete feature set for demo.

What’s next for Wheely Mammoths

Add key features such as: real-time location tracking, pickups via map interface, multi-stop rides, dynamic pricing or seat availability updates.
Integrate payments or cost-sharing (for example splitting gas cost among students).
Build mobile apps (iOS/Android) or mobile-friendly UI, not just desktop/Java prototype.
Establish student verification/trust system (ratings, peer reviews, campus ID integration) to ensure safety and reliability.
Extend to campus communities: API to pull campus maps, shuttle schedules, safe-zones for pickup/drop-off.
Deploy a pilot on a real campus (e.g., in Amherst or other college) to gather user feedback and iterate.
Optimize matching algorithm: more advanced logic (matching by route similarity, detours allowed, seat counting, time windows).
Consider sustainability/impact dimension: reducing solo rides, lowering carbon footprint, perhaps tie into campus sustainability programmes.
Develop a business model: free/paid tiers, partnerships with campus transportation offices, or advertising/sponsorships.