← all work
CS-05V1 complete

Hostel ERP

Bed-level operations for hostels and PGs.

Role
Built alone, end to end
Timeline
2026 · 4 months
Stack
React + ViteMUIExpressSequelize + MySQLPuppeteerMSG91SendGridnode-cron

What it is

Hostel ERP started as software for one real hostel. I rebuilt it into a product any PG or hostel chain could run: branches, rooms, cots, a seven-step admission wizard, fee schedules with electricity charges and late-fee rules, complaints with a full lifecycle, vacate with financial settlement, and a student portal beside the admin one.

The operational core is a nightly job. At 2 AM a guarded nine-stage pipeline generates payment schedules, accrues two kinds of late fees, marks overdue accounts, fires templated reminders, purges expired archives, and releases beds whose checkout time has passed, rewriting branch occupancy counters as it goes. The owner wakes up to a hostel that already did its paperwork.

Before writing the product I wrote the business case: a pricing model researched against 14 competitors, with regional pricing in five currencies. Building the product and deciding what it should cost are the same job.

Architecture

portals
Admin · ~40 pagesStudent · 18 pagesWorker · API ready
api
Express · ~283 endpoints · branch-scoped access
automation
Nightly 9-stage billing cronAlert rules → in-app / email / signed webhooksAnnouncement automations
data
MySQL 8 · 56 modelsInvoice PDFs · PuppeteerExcel import / export
Three portals over one API, with a nightly pipeline doing the paperwork.

Decisions that mattered

01

Branch scoping as a hard boundary

Every request carries the user's accessible branches, and every query intersects with them. A manager of two branches cannot see a third, and a super admin bypass is explicit, not accidental. The multi-hostel tenancy seam is documented in code for the day it is needed.

02

Page-level RBAC that owners configure themselves

Roles map to pages with Full, ReadOnly or None, checked before a route renders. Hostel owners build their own roles from that matrix instead of calling me.

03

Billing as an unattended pipeline

Recurring billing lives on the admission record and feeds a payment schedule with a full late-fee trail. The nightly cron is guarded against double runs and ordered so each stage feeds the next, ending with beds auto-releasing after checkout.

04

Webhooks, because software talks to software

Alert rules fan out to in-app, email and outbound webhooks signed with HMAC, so a chain can wire the ERP into whatever else they run. Announcements support template variables and automation triggers for festivals, due dates and new admissions.

By the numbers

~80,700
lines, built solo
~283
API endpoints
56
database models
58
routed pages across two portals
9
stages in the nightly billing pipeline
14
competitors researched for pricing
5
currencies in the pricing model
16
master data tables owners maintain