More project photos (3)
The problem
Commuting to college in Indian cities usually means overcrowded buses, expensive auto-rickshaws, or half-empty cars burning fuel. Informal carpooling already happens through hostel WhatsApp groups, but it is chaotic: ride offers drown in chat, seats are over-promised, timings shift without notice, and strangers have no way to verify each other. This project replaces that chaos with a proper portal. Only verified college users can participate, every ride has a fixed route, date, departure time and seat count, and bookings decrement live inventory so a seat cannot be sold twice. Drivers build a public rating history and riders see pickup notes and fare terms before they book. Because it is a self-contained full-stack web application with a realistic demo dataset, the student can show every viva concept — session management, relational data modelling, concurrent booking logic and trust features — working live.
Verified student who posts rides with route, date, time, seats, fare and vehicle details.
Follow the working sequence
How it works
- A driver opens the Offer tab and fills the ride form: pickup, destination, date, departure time, seats, fare, vehicle and pickup note.
- The portal validates the form (route endpoints must differ, fares within a sensible range) and publishes the ride to the live listings.
- A rider searches with from/to/date/seat filters; the engine matches rides and renders cards with remaining seats and per-seat fare.
- Clicking Book opens a seat modal; the rider picks a seat count, sees the total fare, and confirms — inventory decrements atomically.
- The booking lands in My Bookings with a Confirmed status and the driver's contact; cancelling restores the seats to inventory.
- After the trip, riders leave reviews and ratings on the driver profile, which updates the driver's public average and trip history.
Tech stack:
- HTML5, CSS3, vanilla JavaScript (single-file demo)
- Node.js + Express (optional deploy variant) or PHP backend per order
- MySQL / SQLite relational data model (users, rides, bookings, reviews)
- Session-based authentication with verified-user roles
- REST-style JSON endpoints for rides, bookings and reviews
- Report: LaTeX/PDF report toolchain; PPT for the final review
| Parameter | Value |
|---|---|
| Application type | Full-stack web portal (single-file demo + documented multi-file source) |
| User roles | Rider, Driver, Admin (role-based views in the build) |
| Search dimensions | Pickup point, destination, date, minimum seats |
| Booking model | Seat-count modal with atomic inventory decrement (design target: no double-booking under sequential use) |
| Demo dataset | Approximately 9 seeded rides, 9 drivers, 10 campus waypoints, 4 reviews |
| Concurrent users | Designed for typical campus pilot load (design target: ~200 concurrent riders) |
| Browsers | Any modern browser; responsive layout for desktop and mobile |
| Deliverable size | Single-file demo under 1 MB; source archive with report and PPT |
Project features
- [Ride posting with fixed routes] Drivers publish rides with pickup, destination, date, departure time, seat count, fare per seat, vehicle details and pickup notes; listings validate inputs and reject impossible routes.
- [Route search and filters] Riders search by from/to points, date and minimum seats, with all results rendered as live cards showing driver, rating, fare and remaining seats.
- [Live seat booking] Booking opens a seat-count modal, confirms total fare, and decrements inventory immediately; cancelled bookings release seats back to the pool.
- [My bookings dashboard] Each rider's confirmed and pending bookings appear in one table with route, fare, status and one-click cancellation.
- [Driver and rider profiles] Profiles carry college-verified badges, rating averages, trip counts, on-time records, rider reviews and the registered vehicle on record.
- [Trust and verification model] Only verified campus users can post or book, reviews are tied to completed bookings, and driver contact is revealed only on confirmation.
- [Working single-file demo] The delivered portal runs as a self-contained web app with a realistic Indian-campus dataset (routes, drivers, fares, reviews) for the viva demonstration.
What is included
- Working CampusRide web portal (single-file demo) with realistic campus dataset
- Full source code with comments and a documented data model (users, rides, bookings, reviews)
- Project report PDF (background, problem, methodology, architecture, screenshots, testing)
- PPT presentation for the final review
- Viva Q&A preparation document (authentication, booking logic, verification model, deployment)
- Offer-ride, search-filter, booking and profile workflows all demo-ready
Limitations & prerequisites
- The demo dataset is seeded and simulated in-browser; real-time GPS tracking and live maps are future scope, not part of the delivered build.
- Payment is recorded as cash/UPI-at-pickup — no payment gateway integration is included in the standard build.
- Push notifications and SMS alerts are out of scope; confirmations render in-app in this version.
- Route matching is by exact waypoint, not fuzzy geocoding — rides between unlisted custom points are not supported.
- The single-file demo holds state in the page; persistent multi-user state needs the documented Node/PHP + database variant, which is described but shipped as source, not as a hosted deployment.
Frequently Asked Questions
How is this different from just booking a cab?
A cab is a commercial service; this portal is peer carpooling among verified students on fixed campus routes, where the fare only splits fuel cost. That difference is also the viva hook: the project is about trust and inventory logic, not a generic booking clone.
How does verification work?
In the build, users are college-verified before they can post or book; the demo represents this with verified badges and a campus email field. The design includes an admin approval step for driver vehicle documents.
What stops two riders from booking the same last seat?
Seat inventory decrements atomically at confirmation and cancelled bookings release seats back. The report documents this concurrency rule explicitly for the viva.
Does it track rides on a live map?
No — live GPS tracking is listed as future scope. The portal covers listing, search, booking, profiles and reviews; map integration would be a documented extension.
Can the demo run offline for the viva?
Yes. The single-file demo needs no server or internet — open it in any browser and every workflow (post, search, book, cancel, review) runs live.
Is this project suitable for a final-year project?
Yes — for Computer Science, IT and Web Development programs. It demonstrates full-stack development, relational data modelling, session management and a trust system, all shown live in the demo. Suitable for B.E./B.Tech final-year projects in Computer Science, IT and Web Development.
Components & software requirements
- HTML5, CSS3, vanilla JavaScript (single-file demo)
- Node.js + Express (optional deploy variant) or PHP backend per order
- MySQL / SQLite relational data model (users, rides, bookings, reviews)
- Session-based authentication with verified-user roles
- REST-style JSON endpoints for rides, bookings and reviews
- Report: LaTeX/PDF report toolchain; PPT for the final review
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.