More project photos (2)
The problem
Finding a PG or flat room usually means scrolling through scattered posts with no rent clarity, no deposit breakup and no idea whether the people already living there share a similar routine. A student may like a room near college but discover later that food preference, sleep timings, cleanliness expectations or guest rules clash, while the total monthly cost is never just the rent — deposit, electricity, Wi-Fi, maid charges and groceries change the real burden. This project brings those decisions into one web application: verified listings are browsed on a map and by filters, roommate profiles are scored for compatibility against stated preferences, and a rent split calculator shows exactly what each person pays before anyone commits.
How it works
- A user registers and logs in with JWT-based authentication, then completes a roommate profile covering budget, food preference, sleep schedule, cleanliness and guests policy.
- Owners or existing tenants post a PG or flat listing with photos, rent, deposit, sharing type and locality; the listing stays pending until an admin approves it in the moderation panel.
- Approved listings appear in browse and map views; filters for budget, area, room type and furnishing narrow the results, and each card shows rent and deposit separately.
- For each listing with existing occupants, and for standalone roommate profiles, the backend compares preference fields and computes a compatibility score with a per-factor breakup.
- The user opens the rent split calculator, enters rent, deposit, number of occupants and shared monthly expenses, chooses equal or custom shares, and sees the per-person monthly and one-time amounts.
- When a room and a match both look suitable, the user sends an enquiry or chat request; the recipient accepts or declines, and only then does the in-app conversation open.
- Admins review reported listings and profiles from the moderation queue and can approve, reject or remove content, with the decision reflected immediately in browse results.
Tech stack:
- React
- Node.js · Express
- MySQL
- JWT authentication
- Leaflet · OpenStreetMap
- HTML · CSS · JavaScript
- REST API
| Parameter | Value |
|---|---|
| User roles | 3 roles — seeker, lister / occupant, admin |
| Preference factors scored | 5 factors — budget, food, sleep, cleanliness, guests policy |
| Compatibility score | 0–100 scale, weighted sum of the 5 factors (design) |
| Calculator inputs | Rent, deposit and up to 6 shared-expense heads (design) |
| Split modes | 2 modes — equal split and custom percentage shares |
| Listing photos | Up to 6 photos per listing (configurable limit) |
| Page response time | Design target: under 2 seconds on a typical broadband connection |
| Concurrent users | Approximately 200 concurrent sessions (design target, not load-tested) |
| Database | MySQL — users, profiles, listings, matches, enquiries, reports |
| Map | Leaflet with OpenStreetMap tiles, locality-level pins |
Project features
- [PG and flat listings with filters] Rooms are listed with photos, rent, deposit, sharing type, furnishing, food availability and locality, and can be filtered by budget, area, room type and gender preference. (Implemented)
- [Roommate preference matching] Each user sets budget, food preference, sleep schedule, cleanliness level and guests policy; the system scores other profiles against those preferences and shows a compatibility percentage with a per-factor breakup. (Implemented)
- [Compatibility score breakup] The score is not a single opaque number — budget overlap, food, sleep, cleanliness and guests policy each contribute a visible sub-score so users can see where a match is strong or weak. (Implemented)
- [Rent, deposit and shared-expense split calculator] Monthly rent, one-time deposit and shared costs such as electricity, Wi-Fi, maid and groceries are entered once and split equally or by custom shares, showing the per-person total clearly. (Implemented)
- [Enquiry and chat request flow] A user sends an enquiry on a listing or a chat request to a matched roommate; the other side accepts before contact details are exchanged in the base build. (Implemented)
- [Admin moderation panel] An admin approves or rejects new listings, flags reported profiles, manages localities and categories, and removes listings that break the stated rules. (Implemented)
- [Saved listings and shortlist] Users save rooms they like and compare shortlisted options side by side on rent, deposit and per-person monthly cost from the calculator. (Implemented)
- Optional / future scope: online payment gateway for rent or token amounts and government ID verification are NOT part of the base build — payments happen outside the app and identity checks are manual; push notifications on mobile and a native mobile app are future scope.
What is included
- Complete source code (React frontend, Node.js · Express backend)
- MySQL database schema with seed listings and sample roommate profiles
- Roommate matching module with per-factor compatibility breakup
- Rent, deposit and shared-expense split calculator
- Admin moderation panel for listings and reported profiles
- Setup and hosting guide (local run plus deployment steps)
- Project report PDF (background, architecture, methodology, results)
- PPT presentation for final review
- Viva Q&A preparation document (matching logic, database design, authentication, split calculation)
Limitations & prerequisites
- Listings are only as reliable as their posters — the admin moderation step reduces stale or misleading posts but cannot physically verify every room.
- Matching is preference-based and rule-based, not a safety guarantee; it does not verify character, payment history or behaviour, and users should meet in a public place first.
- Map pin position depends on the geocoding of the entered address; some listings show locality-level rather than exact building location.
- Government ID verification is not included in the base build; identity checking, if a college requires it, is a manual or optional step.
- No payment gateway is integrated in the base build, so rent, deposit and token payments are handled outside the application.
- Hosting, domain and any paid map or SMS services are separate costs and are not part of the software itself.
- Compatibility weights are fixed in the base configuration; learning weights from user outcomes is future scope, not implemented.
Frequently Asked Questions
Is this project suitable for a final-year project?
Yes — for Computer Engineering, Information Technology and Web Development programmes. It demonstrates a complete full-stack build: relational database design across users, listings and enquiries, JWT authentication, a rule-based matching algorithm with an explainable score breakup, a financial split calculator, map integration and an admin moderation workflow, all of which give concrete technical material to explain and defend in a viva.
Is the database included and how is it structured?
Yes, the MySQL schema is included with seed data. Core tables cover users, roommate profiles with preference fields, listings with photos and locality, enquiries and chat requests, saved listings and moderation reports. Foreign keys link listings to their lister, enquiries to both parties, and reports to the listing or profile involved, so the data model can be shown as an ER diagram in the report and explained table by table.
Does the project contain an admin panel?
Yes, admin moderation is part of the base build. An admin approves or rejects new listings before they appear publicly, reviews reported listings and profiles, manages localities and categories, and can remove content that breaks the rules. This moderation queue is important for the viva because it shows how user-generated listing platforms control stale, duplicate or misleading posts instead of publishing everything automatically.
Can it be hosted online and what does hosting need?
Yes, the build can be hosted on a standard Node.js and MySQL hosting setup or a small VPS. The frontend is served as a static build, the Express API runs as a Node process, and MySQL holds the data. Hosting, domain and any paid tile, storage or SMS usage are separate recurring costs paid to the provider; the included guide covers environment variables, database import and the production build steps.
How does the compatibility score work?
The score is a transparent weighted sum, not a black box. Budget overlap, food preference, sleep schedule, cleanliness level and guests policy are each compared between two profiles and scored, then combined into a 0–100 result with the per-factor breakup shown on screen. Equal or close preferences score high, direct clashes score low, and the weights are configuration values that can be adjusted and discussed during the viva.
Is a payment gateway or ID verification included?
No, neither is part of the base build, and this is stated plainly. There is no payment gateway for rent or deposit, and no automated government ID verification; enquiries and chat requests are the contact flow, and any payment or identity check happens outside the app. Adding a payment gateway or a third-party verification service is a realistic optional customisation if a college specifically requires that flow.
Components & software requirements
- React
- Node.js · Express
- MySQL
- JWT authentication
- Leaflet · OpenStreetMap
- HTML · CSS · JavaScript
- REST API
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 email — the synopsis PDF downloads immediately. We may send occasional project updates; no spam, unsubscribe anytime.