Building a Hostel Management System That 53 People Actually Use

Quick context since this is the first thing I'm publishing here: I'm Dhruv, a full-stack engineer and CS student, and most of what ends up on this blog will come out of things I've actually built rather than things I've read about. I've shipped a handful of projects across a few different stacks, and two of them are live products real people use right now, not portfolio demos. HMS is one of them, and it's the one I want to start with.

Why HMS, specifically

I built HMS because I lived in the hostel it now runs. The meal tracking, the complaints, the fee records, I dealt with all of it as a resident before I dealt with any of it as a developer. That's a different starting point than picking a project idea off a list.

It's also different from my other projects in ways that actually matter to me. The rest had some structure around them, an internship, a team, someone to check decisions with. HMS didn't have any of that. Every call was mine, and still is. The people using it aren't anonymous either, I know the warden, I know the kitchen staff, and if something's wrong I hear about it directly. There's also no company behind it if it breaks before breakfast. There's just me, for as long as it keeps running.

So here's what it actually does day to day, and why each part turned out to matter more than it looked like it would on paper.

It does three things. Students mark their meals and their attendance. The warden handles room allocation and complaints. Fees and dues get tracked so nobody has to remember who paid what by hand. None of that sounds hard on paper. Each one turned out to be more load-bearing than I expected once real people depended on it every day.

The meal count isn't a dashboard number

The kitchen staff use that number to decide how much food to actually cook that morning. If the count is wrong, it isn't a bug ticket, it's wasted food or someone going hungry, and there's no fixing it after the fact. A number that's just displayed on a dashboard in most apps is an instruction to buy groceries in this one.

A status field is a promise

A maintenance request marked resolved when it isn't doesn't just look bad in the data. It's a student who reported a broken tap or a light that doesn't work, checking the app, seeing "resolved," and still living with a broken tap. The status field isn't a status field. It's whether someone believes the system is actually listening.

Money doesn't round the way UI does

Fees are the most unforgiving of the three, because they're money. A number that's off by even a small amount isn't a rounding error, it's a dues reminder sent to someone who already paid, or one that doesn't get sent to someone who didn't. Both of those are the kind of mistake people remember.

Boring technology, on purpose

None of this is complicated engineering. The backend is NestJS, Prisma, and Postgres. The app is React Native. I didn't pick any of that to be interesting, I picked it because it's boring in the way you want infrastructure to be boring when actual people are depending on it working correctly every single day. A hostel doesn't pause because your ORM has an interesting new release. It runs on the same schedule whether the code is ready or not.

The mistake doesn't stay private

I don't think that makes the code special. Plenty of people build systems more complex than this one. What it changed was the bar I hold my own work to afterward. Before I ship something now, the real question isn't "does this work," it's closer to "would I trust this the way the kitchen staff have to trust the meal count." Most of my other projects don't need to clear that bar. This one does, every morning, whether I remember that or not.

More of what I'm building

Two of my other projects are live if you want to look: Clarityy AI, a portfolio-analytics platform for Indian investors, and DevPain-AI, a small tool that analyzes developer pain points.

You can also find me on GitHub and LinkedIn. More of this is coming.

— Dhruv