Hostel management system project
rooms, fees, out-passes and an ER diagram
Blocks, rooms and beds, room allocation, hostel and mess fees, out-passes, visitors and complaints, with logins for the warden and students. Generate a working version, then make it yours.
What the project does
Generated from the prompt below, so yours can differ: read it before you present it.
Rooms and beds
Blocks, rooms with floor, type and capacity, and beds, with occupancy shown per block.Room allocation
Students apply, the warden allocates a free bed. Allocation never goes beyond a room's capacity.Fees and dues
Hostel and mess fees per semester, payments with receipt numbers and the list of students with dues.Out-passes
A student requests leave with leaving and return times; the warden approves or rejects; late returns are flagged.Visitors and complaints
A visitor log with time in and out, and room complaints with a category and status until they are closed.Notices
Announcements to every resident or to one block.Who uses it
- Warden
- Manages rooms and allocation, fees, approves out-passes, closes complaints, posts notices.
- Student
- Applies for a room, pays fees, requests out-passes, raises complaints, reads notices: only their own records.
ER diagram
Eight entities. Allocation is the history of who held which bed when, so a room change adds a row instead of overwriting the last one.
block
| id | uuid | PK |
| name | text | |
| gender | text |
room
| id | uuid | PK |
| block_id | uuid | FK |
| room_no | text | |
| floor | int | |
| type | text | |
| capacity | int |
student
| id | uuid | PK |
| roll_no | text | UK |
| name | text | |
| course | text | |
| guardian_phone | text |
allocation
| id | uuid | PK |
| student_id | uuid | FK |
| room_id | uuid | FK |
| bed_no | int | |
| from_date | date | |
| to_date | date |
fee
| id | uuid | PK |
| student_id | uuid | FK |
| kind | text | |
| amount | numeric | |
| paid | numeric | |
| due_on | date |
outpass
| id | uuid | PK |
| student_id | uuid | FK |
| leaves_at | timestamp | |
| returns_at | timestamp | |
| reason | text | |
| status | text |
visitor
| id | uuid | PK |
| student_id | uuid | FK |
| name | text | |
| relation | text | |
| in_at | timestamp | |
| out_at | timestamp |
complaint
| id | uuid | PK |
| room_id | uuid | FK |
| student_id | uuid | FK |
| category | text | |
| status | text |
Relationships
- block contains room (one to many)
- room is allocated in allocation (one to many)
- student holds allocation (one to many)
- student owes fee (one to many)
- student requests outpass (one to many)
- student receives visitor (one to many)
- room has complaint (one to many)
- student raises complaint (one to many)
Mermaid source
Paste it into mermaid.live, draw.io (Arrange, Insert, Advanced, Mermaid) or any Markdown editor that draws Mermaid to get the diagram for your report.
erDiagram
BLOCK ||--o{ ROOM : "contains"
ROOM ||--o{ ALLOCATION : "is allocated in"
STUDENT ||--o{ ALLOCATION : "holds"
STUDENT ||--o{ FEE : "owes"
STUDENT ||--o{ OUTPASS : "requests"
STUDENT ||--o{ VISITOR : "receives"
ROOM ||--o{ COMPLAINT : "has"
STUDENT ||--o{ COMPLAINT : "raises"
BLOCK {
uuid id PK
text name
text gender
}
ROOM {
uuid id PK
uuid block_id FK
text room_no
int floor
text type
int capacity
}
STUDENT {
uuid id PK
text roll_no UK
text name
text course
text guardian_phone
}
ALLOCATION {
uuid id PK
uuid student_id FK
uuid room_id FK
int bed_no
date from_date
date to_date
}
FEE {
uuid id PK
uuid student_id FK
text kind
numeric amount
numeric paid
date due_on
}
OUTPASS {
uuid id PK
uuid student_id FK
timestamp leaves_at
timestamp returns_at
text reason
text status
}
VISITOR {
uuid id PK
uuid student_id FK
text name
text relation
timestamp in_at
timestamp out_at
}
COMPLAINT {
uuid id PK
uuid room_id FK
uuid student_id FK
text category
text status
}Generate yours and get the code
This builds on Refinar's school starting point, which already has residents with their parents, a daily register and fees with receipts. Rooms, allocation, out-passes and complaints come from the prompt. Running a real college hostel? See the hostel management system page instead.
The button opens Refinar with the project described in the first message, ready to edit. About a minute later there is a running app with sign-in, the pages above and a PostgreSQL database, in a live preview you can click through and change by asking.
It is real code: Next.js and React in TypeScript, PostgreSQL with the Drizzle ORM, and Better Auth for sign-in. When you press Go live, the GitHub repository moves to your own GitHub account and the database to your own Neon account, so you can read it, run it and present it. Building uses credits and going live needs a Refinar plan; the details are on the pricing page.
If your syllabus asks for PHP and MySQL, Java or Python, ask your guide before you start: the generated code will not be in those languages. The ER diagram and the checklist on this page work for any stack.
The prompt it starts with
A hostel management system for a final-year project, in English: blocks, rooms with floor, type and capacity, and beds; students apply for a room and the warden allocates a bed, never beyond capacity; hostel and mess fees per semester with payments and dues; out-pass requests with leaving and return times that the warden approves or rejects; a visitor log; complaints about a room with a category and status; notices. Roles: warden, who does everything, and student, who sees their room, fees, out-passes and complaints only.
Report and viva checklist
Report checklist
- Abstract: the problem, who uses the system and what it does, in one paragraph.
- Existing system and its problems, then the proposed system.
- Objectives and scope, including what is out of scope.
- Requirements: functional and non-functional, per role.
- Technology used and why: Next.js, TypeScript, PostgreSQL, Drizzle ORM.
- ER diagram and table design, normalised to third normal form.
- DFD level 0 and level 1, and a use case diagram.
- Module description with a screenshot of each screen.
- Testing: test cases with input, expected result and actual result.
- Conclusion, limitations and future scope.
- References, and a statement of the tools you used, AI included.
Make the report about this project
- Explain how the app refuses an allocation beyond capacity, and where that rule lives.
- Draw the out-pass flow: requested, approved or rejected, left, returned, returned late.
- Show the query that lists empty beds per block.
- Test cases: allocating a full room, approving an out-pass twice, a student viewing another's fees.
Viva questions to prepare
- Why keep allocation history instead of a room_id column on the student?
- How would you handle two wardens allocating the last bed at the same time?
- What would you add for a mess attendance or meal count?
- How would a parent be told when their child leaves on an out-pass?
- What is a primary key and a foreign key? Point to one of each in your tables.
- Which normal form are your tables in, and what would break if they were not?
- How does sign-in work, and how are passwords stored?
- How does the app stop one user from seeing another user's data?
- Why PostgreSQL, and not MySQL or MongoDB?
- What did you change or add yourself, and why?
Build it, understand it, then submit it
Many universities allow tools, AI included, as long as you say so and can explain every part of what you submit. Read your university's rules and ask your guide before you start, and name Refinar in the tools section of your report.
Treat the generated app as a starting point, not a submission. Read every table and every page, change something yourself, add one feature that is your own, and write the test cases by hand. If you cannot say why a table has a foreign key, an examiner will find out in a minute.
Submitting work you did not do and do not understand as your own is academic misconduct, whoever or whatever wrote it. These pages are here to help you build a project you can defend.
Take it further
- A parent login that shows out-passes and fee dues.
- A QR gate pass scanned by the security guard at exit and entry.
- Mess menu and meal counts per day.
- Automatic room allocation by course and year.
Questions
What modules does a hostel management system project need?
Rooms and beds, allocation, fees, out-passes or leave, visitors, complaints and notices, with a warden login and a student login.
How is this different from a hotel booking project?
A hostel houses the same residents for a term, so the work is allocation, fees and rules such as out-passes. A hotel sells nights to guests, so it is about availability, rates and bookings.
Can I add attendance?
Yes. A night roll call per block is a natural extension, and the school starting point already has a daily register to build it from.
Is it free?
Building uses credits from a Refinar plan, and getting the code into your own GitHub account goes through Go live, which needs a plan. The details are on the pricing page.
More project ideas
- Hospital management systemPatients, doctors, appointments, prescriptions, wards and bills, with a login per role.
- Library management systemCatalogue, copies, issue and return with due dates, fines and reservations.
- Student management systemStudents, courses, attendance, marks and results, fees and a student login.
- Pharmacy management systemMedicines, batches and expiry, purchases, sales bills and stock alerts.
- E-commerce websiteStorefront, cart, checkout, orders with status, customer accounts and a stock admin.
- Event management systemEvents with ticket types, registration, QR check-in at the door and feedback.