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

iduuidPK
nametext
gendertext

room

iduuidPK
block_iduuidFK
room_notext
floorint
typetext
capacityint

student

iduuidPK
roll_notextUK
nametext
coursetext
guardian_phonetext

allocation

iduuidPK
student_iduuidFK
room_iduuidFK
bed_noint
from_datedate
to_datedate

fee

iduuidPK
student_iduuidFK
kindtext
amountnumeric
paidnumeric
due_ondate

outpass

iduuidPK
student_iduuidFK
leaves_attimestamp
returns_attimestamp
reasontext
statustext

visitor

iduuidPK
student_iduuidFK
nametext
relationtext
in_attimestamp
out_attimestamp

complaint

iduuidPK
room_iduuidFK
student_iduuidFK
categorytext
statustext

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.