User registration and login
The application includes account registration plus separate login experiences for driver/car-owner, user/client, and administrator roles.
← Back to projects
Project 08 / Full-stack web application
WEE RIDE — Carpooling & Ride Sharing
A carpooling and ride-sharing application built as an academic team project, connecting driver, passenger, and administrator workflows around shared rides.
01 / PassengerDiscover & requestBrowse available vehicles, manage bookings
02 / DriverReview & manageBooking requests and trip status
03 / AdministratorOversee operationsVehicle records, users, booking status
Browser · HTML / CSS / Bootstrap / AngularJS↓ HTTP requests ↑PHP application · Apache / XAMPP↓MySQL · application records
Simplified view of the documented application structure. The original presentation diagram is replaced here because its small text and mixed flow arrows were difficult to read.
The problem
Make everyday travel more shareable when traffic, cost, and rigid transport options create friction.
The project presentation frames the problem around heavy urban traffic, pollution, inconsistent public-transport schedules, and the cost of individual travel. It explores carpooling as a way to connect people travelling in compatible directions while making better use of existing vehicles.
The solution
Organize shared rides around clear driver, passenger, and administrator workflows.
WEE RIDE was developed as a web-based carpooling system with three primary roles. Drivers manage trip information and incoming ride requests, users search for available trips and request seats, and administrators monitor the system and manage application data.
Register→Search or offer ride→Request→Driver review→Ride history→Admin oversight
Core features
The supplied project material demonstrates the main account, ride, request, and administration flows.
Driver / car-owner workflow
Driver screens show trip/account details, booking requests from users, and a request-management view for reviewing ride participation.
User / client workflow
User screens demonstrate searching available trips, opening ride details, requesting rides, and reviewing past rides.
Administration
The administrator interface includes a dashboard, monitoring/control screens, and data-management views for the application's operational records.
Ratings and community ideas
The presentation lists a rating/review system and community connection among intended platform capabilities; the supplied screenshots do not verify these as implemented screens.
Proposed location-aware tracking
The presentation lists Google Maps ride tracking as a platform capability, but the available application captures do not demonstrate an integrated live-tracking feature.
System architecture
Use a browser-based UI with the PHP/MySQL application stack documented in the project presentation.
The original web-application diagram identifies HTML, CSS, Bootstrap and AngularJS on the interface side, PHP and MySQL in the application/data stack, XAMPP with Apache/MySQL for the local environment, and HTTP POST/GET with JSON responses between browser and server. The diagram above simplifies this documented stack for readability without introducing additional technologies.
Browser UIHTML · CSS · Bootstrap
→
AngularJSclient-side interaction
→
PHPapplication requests
→
MySQLapplication data
Original application evidence
Explore the working screens across passenger, driver, and administrator journeys.
The application screens below are the original captures supplied for the TechnoThought presentation, not borrowed reference-site screenshots. Open any image to zoom and pan at its source resolution. Sensitive password text in the driver account form has been obscured.
01 / Entry and onboarding
The landing page and registration form introduce the application. Separate client and driver login screens demonstrate the role-specific entry points.
02 / Passenger journey
Passengers can explore available rides and inspect booking details and history. The status labels in these screenshots are application states, not measured ride outcomes.
03 / Driver and car-owner journey
The driver-facing screens cover account management, booking status, and expanded trip details.
04 / Administrator journey
The administrator screens cover entry, dashboard summaries, booking oversight, and application settings.
05 / Data-flow model
The original high-level data-flow diagram outlines the major management areas around the carpooling system. It is a conceptual model, distinct from application screenshots.
Source: WEE RIDE TechnoThought 2024 presentation, particularly slides 7–13, supplemented by the original application captures. Presentation ideas such as Android support, GPS tracking, and machine-learning route optimization are not treated as verified implemented functionality.
Engineering challenges
Coordinate multiple roles and ride states without turning research ideas into claimed implementation.
The source material does not document a bug-by-bug development diary, so these are the engineering challenges visible in the demonstrated system rather than invented incident stories.
01 · Multi-role workflow design
Drivers, passengers, and administrators need different screens and actions while still operating on the same ride and booking information.
02 · Ride and request state
The user journey spans ride discovery, a booking request, driver review, status updates, and ride history, which requires consistent state across several views.
03 · Frontend-backend-data flow
The project architecture connects browser interfaces to PHP/MySQL through HTTP requests, so forms, request handling, and stored records need to agree on the same data flow.
Results & key learnings
A working academic demonstration of role-based carpooling workflows.
Account workflow
The project demonstrates registration and role-specific login entry points.
Ride discovery and requests
User screens show available trips and ride-request workflows, while driver screens show incoming booking requests and request management.
Administrative visibility
The dashboard and data-management interfaces demonstrate system-wide oversight of operational records.
The project provided practical exposure to full-stack workflow design, role-oriented interfaces, form/data handling, browser-to-server communication, relational data, and turning an application idea into a demonstrable multi-screen system. The supplied material does not establish production deployment, scale, performance benchmarks, or commercial usage.
Team context
Present the work accurately as a collaborative academic project.
The project presentation credits three student team members, including Asmita G V. It does not document a reliable breakdown of individual implementation responsibilities, so this case study does not assign sole authorship or invent personal contribution claims.
Future improvements
Extend the platform beyond the demonstrated web workflows.
The presentation lists multilingual support, integration with campus events, enhanced security measures, and integration with public transportation as future directions. These are presented here as proposed improvements, not completed features.