In ProductionLead Engineer & DesignerFlagship · Advanced

Hostel Management

Digitise hostel operations end to end.

Hostel Management transforms the paper-and-spreadsheet nightmare of running a college hostel into a clean, real-time digital system — giving wardens, administrators, and students a single source of truth for every room, fee, and complaint.

Live Demo

The Story

Why this exists.

The Problem

Most college hostels still run on manual processes: room allocation in Excel, fee collection tracked in registers, complaints submitted on paper slips. Wardens spend hours on admin. Students wait days for responses. Errors in fee records cause disputes. There is no audit trail.

Why It Matters

A hostel houses hundreds of students. When its administration is broken, real problems follow — fee disputes, untracked maintenance issues, misallocated rooms. Digitising operations isn't just efficiency; it's accountability.

The Solution

A Next.js + Supabase full-stack application with modules for room allocation, student records, fee tracking with payment history, complaint management, and a warden dashboard with real-time occupancy overview.

Product Features

What it does.

Room Allocation Dashboard

Visual floor map showing room occupancy, vacancy, and maintenance status. Drag-and-drop allocation with conflict detection.

Fee Management

Track monthly fees, pending dues, and payment history per student. Auto-generate receipts and outstanding balance reports with one click.

Complaint Tracking

Students submit complaints digitally — categorised by type (maintenance, cleanliness, security). Wardens assign and track resolution status with timestamps.

Occupancy Analytics

Real-time occupancy rates, vacancy trends, and revenue forecasts. Monthly and semester-wise breakdowns for administrative planning.

Role-Based Access

Wardens manage their own floors. Admins oversee the full hostel. Students access only their own profile and complaints. All enforced by Supabase RLS.

System Architecture

How every layer connects.

FrontendNext.js 14 + TypeScriptDashboard UI, room map, fee tables, complaint tracker

BackendNext.js API RoutesCRUD for rooms, students, fees, complaints

DatabaseSupabase PostgreSQLAll operational data with RLS policies

AuthSupabase AuthEmail auth, role assignment (Admin/Warden/Student)

StorageSupabase StorageStudent ID documents, complaint attachments

DeploymentVercelEdge CDN, serverless API routes

Technical Deep Dive

Under the hood.

Room Allocation with Conflict Detection

Room allocation runs a check before committing: is the room occupied? Is the student already assigned elsewhere? Is the room under maintenance? These three checks happen in a single PostgreSQL transaction — if any fails, the whole allocation rolls back. This prevents the double-allocation bugs that plagued the previous Excel-based system.

-- Atomic room allocation with conflict check
BEGIN;
  SELECT 1 FROM rooms WHERE id = $1 AND status = 'vacant' FOR UPDATE;
  SELECT 1 FROM students WHERE id = $2 AND room_id IS NULL FOR UPDATE;
  UPDATE rooms SET status = 'occupied', student_id = $2 WHERE id = $1;
  UPDATE students SET room_id = $1 WHERE id = $2;
COMMIT;

Fee Calculation Engine

Fees are computed from a base hostel fee, optional meal plan, and any ad-hoc charges (laundry, guest stay). The calculation is done server-side on demand — no denormalised balance fields that can drift. A Supabase function computes the current balance by summing charges and subtracting payments, returning a consistent view every time.

Engineering Decisions

Challenge → Decision → Result.

Room allocation atomicity — preventing double allocation

Decision

PostgreSQL transactions with SELECT FOR UPDATE

Why

Application-level checks have TOCTOU race conditions. Database-level locks with FOR UPDATE prevent concurrent allocation of the same room.

Result

Zero double-allocation incidents since deployment.

Fee balance — computed field vs. stored balance

Decision

Computed on demand via DB function

Why

Stored balances drift when payments are edited or reversed. Computing from source records is always consistent.

Result

Zero fee discrepancy disputes in 6 months of production use.

Performance & Scale

By the numbers.

800+Students Managedacross 3 hostel blocks

0Fee Disputesin 6 months of production

2.1 daysComplaint Resolutionavg time-to-close

0Double Allocationssince atomic allocation

Deployment & Infrastructure

Production setup.

Deployment

Next.js on Vercel. Supabase PostgreSQL with RLS. Supabase Auth for multi-role login. Supabase Storage for documents. Production database in ap-south-1 (Mumbai) for low latency.

CI/CD

GitHub Actions — TypeScript + ESLint on PR. Auto-deploy to Vercel on merge.

Monitoring

Supabase dashboard for slow queries and Auth events. Vercel Analytics for UI performance.

Challenges & Failures

What broke — and how I fixed it.

Challenge

Wardens editing each other's floor data due to misconfigured RLS policy.

Fix

Rewrote RLS policies with explicit floor_id scoping — each warden can only modify records where floor_id matches their assigned floor.

What I Learned

Key takeaways.

01
PostgreSQL transactions are the right tool for allocation problems — optimistic locking at the application layer is not.
02
Computed balances from source records are always more trustworthy than stored derived fields.
03
RLS policy testing needs dedicated test cases — a misconfigured policy is a security and data integrity issue.

Future Roadmap

Where this is going.

v2.0 — 2026

—Online fee payment with Razorpay integration
—WhatsApp notifications for fee reminders and complaint updates
—Visitor management log with entry/exit tracking

Screenshots

The product.

Warden dashboard — room occupancy overview

Complaint management with status tracking

Technology Stack

Built with.

Frontend

Next.js 14TypeScript

Backend / DB

Supabase

Database

PostgreSQL