HostelLo

HostelLo is a student accommodation platform, connects residents with hostel owners. It uses dual profiles and an smart "habits-match" mechanism to assign suitable rooms and compatible roommates.

Comment

Inspiration

Anyone who's lived in a hostel or PG as a student in India knows how this goes. You scroll through blurry photos on some broker's WhatsApp, blow a Sunday visiting three places, pick one on vibes, and pray your roommate isn't a nightmare.

The student housing market here is huge and a mess. Beyond a few basic listing directories, almost none of it is digitised. Nothing's standardised, nothing's verified, and there's zero intelligence behind any of it. You can't actually tell from a listing whether a hostel fits how you live before you commit to it. And once you've moved in, you have no idea if the person sharing your room is going to make your life hell.

We'd all been through some version of that. So we wanted to fix both halves of the problem in one product.

What it does

HostelLo is a dual-profile hostel management platform. It connects students looking for a place with property owners, but with a smarter layer on top that we haven't seen on any Indian hostel platform.

A student fills out a habits questionnaire: sleep schedule, cleanliness, study habits, diet, how social they are, that kind of thing. The matching engine then scores every available listing on price fit, location, amenities, and how well the owner's tenant criteria line up with the student's profile. Instead of a wall of identical-looking listings, you get a ranked, personalised set of results with a score breakdown for each dimension.

Pick a shared room and the roommate engine kicks in. It scores current and incoming residents against each other on those same habits and ranks them by compatibility. Booking a shared room then kicks off a mutual consent flow, where both people have to actively accept the match before anything's confirmed. If one of them says no, the engine just moves to the next candidate.

On the owner side, owners list their hostel with tenant criteria, add rooms with photos, and look over who's applying. What they can see about a resident depends on where things are in the booking lifecycle: habits score and compatibility breakdown while they're reviewing, full contact details only once a booking is confirmed. That gating follows India's DPDP framework.

How we built it

We split the system into three layers early on so each part could change on its own.

The matching engine (app/engine/) is a set of plain Python functions with no framework dependencies at all. Hostel scoring and roommate ranking both live here, and both are unit-tested in isolation. The output isn't one black-box number. It's a scored vector across several dimensions, and the UI draws it as per-dimension bars so a student can actually see why a hostel or a roommate landed where it did.

The service layer (app/services/) handles anything stateful: booking allocation with ordered-lock transactions, the lifecycle cascade when a room hits capacity, and the candidate pool that feeds the roommate engine.

The API and privacy layer (app/routers/ plus app/serializers.py) is where DPDP compliance actually lives. Every response runs through an explicit allowlist serializer tied to the current booking stage and the requester's role. We didn't use any generic field-exclusion shortcuts anywhere.

The frontend is a mobile-first React + TypeScript SPA, around 33 screens, served same-origin by FastAPI in production. Auth is OTP to JWT stored in an httpOnly cookie. No passwords, and no token sitting in localStorage.

Challenges we ran into

The hardest part was the mutual consent flow for shared rooms. When two students want to share, two booking records have to confirm atomically, and every other pending request for that bed has to be killed at the same instant. The obvious design keeps consent outside the transaction: student A books, student B gets a notification, B accepts. But if B declines after A's already shown as confirmed, you're left with a broken state to unwind by hand. Pulling consent inside the transaction, so nothing confirms until both people accept, kept the state machine coherent no matter the timing or how much concurrent load hit it. We did it with ordered-lock transactions and a cascade invalidation sweep.

DPDP compliance shaped the whole API design too. We couldn't bolt privacy onto a generic user model after the fact. Each serializer is an explicit allowlist, rebuilt for every lifecycle stage and every role, which means the privacy model is auditable instead of something we'd have to reverse-engineer when a review came around.

Accomplishments that we're proud of

The matching engine gives you a readable score breakdown, a vector the UI renders as per-dimension bars rather than one opaque number. That's the thing that makes the product trustworthy instead of just clever. And because it's a pure function decoupled from the web layer, we can tweak weights, add new dimensions, and run experiments without ever touching the API.

We're also proud of getting the booking transaction right. Atomic dual-confirmation with cascade invalidation is easy to get subtly wrong under load, and the ordered-lock approach has held up cleanly in production.

And honestly, shipping a full dual-profile product as a small team, with a working matching engine, a consent-gated booking flow, and DPDP-compliant data gating, is something we're happy with.

What we learned

Consent is a product feature, not a legal checkbox. Moving mutual roommate consent into the booking transaction instead of treating it as a notification you fire off later ended up shaping everything downstream: the serializers, the state machine, the candidate pool logic, even the UI flow. One product decision rippled through the whole architecture.

The dual-profile design is the product. It would've been easier to build a resident-only app and treat owners as a back-office afterthought. But the matching engine only works if owners actually specify tenant criteria, which means owners need a real, well-designed experience too. You can't separate the two sides.

Build the engine as a pure function first. Since the matching logic has no framework dependencies, we could iterate on scoring weights and test edge cases without standing up the full API. That paid off faster than we expected.

What's next for HostelLo

Right now the compatibility scores are heuristic: weights we picked based on what we reasoned should matter. The obvious next step is making them predictive, trained on real booking outcomes. Pairs who stuck it out for a full semester versus pairs who asked to switch rooms. Once we've got enough data, the learned model replaces the heuristic and the scores stop being guesses.

We also want owner-side analytics: fill rates, where people drop off in the booking funnel, how often roommate matches get accepted. And we want to go beyond traditional hostels into PG accommodations, which in most Indian cities is actually the bigger market.

Built With

  • alembic
  • cloudinary
  • cloudinary-(room-image-storage)-**auth**-otp-based-authentication
  • dpdp
  • fastapi
  • full-stack
  • hostel-management
  • javascript-**frameworks-&-libraries**-fastapi
  • jwt
  • jwt-(httponly-cookies)-**other**-dpdp-compliant-data-serialization
  • matching-algorithm
  • mobile-first
  • neon
  • postgresql
  • privacy-by-design
  • pydantic
  • pydantic-**database**-postgresql-(hosted-on-neon)-**cloud-&-hosting**-render
  • python
  • react
  • reactspa
  • render
  • rest-api
  • roommate-matching
  • sqlalchemy
  • student-housing
  • tailwind-css
  • typescript
  • vite
Share this project:

Updates