LFGroupBot

Inspiration

RCs are social by nature, but some may be shy to just text in the main RC chat to ask people to play Mahjong, hop on a Switch, or shoot some pool right now. We wanted to build something that lives where students already are: Telegram, making it effortless to find people and coordinate without downloading yet another app.

What it does

LFGroupBot is a Telegram bot that turns RCs into coordinated gaming hubs. Guests can:

🎮 Create or join gaming sessions across categories like Mahjong, Nintendo Switch, PlayStation, board games, pool, and more — all in a few button taps via /lfg and /browse
📦 Check and reserve shared resources (TVs, game consoles, tables) with automatic time limits and checkout reminders
🏨 Work across multiple RCs, with each RC managing its own residents, resources, and group categories according to each RC's needs

RC staffs get a full admin panel to approve users, manage resources, create custom categories, oversee all active groups, view usage statistics, and auto-post new sessions to a public announcement channel.

How we built it

Bot Framework: grammY — a modern TypeScript-first Telegram Bot API library with excellent middleware support
Database: Supabase (PostgreSQL) — handling users, hostels, groups, resources, sessions, and admins with Row Level Security for hostel data isolation
Language: TypeScript throughout, targeting ES2022
Runtime: Node.js with long polling for local development; the architecture is designed to migrate cleanly to Cloudflare Workers with webhooks and Cron Triggers for production
Background Jobs: A scheduler (setInterval-based locally) runs three recurring tasks — notification checks every 5 minutes, group/resource expiry cleanup every 15 minutes, and data archival every hour
Middleware stack: layered auth (user approval gating), admin privilege checks, and in-memory rate limiting per user action type

Challenges we ran into

Stateful multi-step conversations in a stateless bot model — Telegram bots are inherently event-driven, but creating a group involves 4–5 sequential steps (category → title → player count → timing → resource). Tracking per-user conversation state cleanly without a full conversation framework required careful in-memory state management.
Resource contention and race conditions — ensuring a resource can't be double-booked when two users tap "Check In" simultaneously required careful database-level checks rather than relying on application-layer state.
Multi-tenancy isolation — making sure users at RC A can never see or interact with data from RC B, enforced both at the application layer and via Supabase Row Level Security policies.
Scheduler reliability — background jobs (notifications, auto-expiry, archival) need to be reliable even if they miss a cycle; all jobs are idempotent and re-runnable safely.

Accomplishments that we're proud of

A genuine working prototype, with auth middleware, rate limiting, error handling, data archival, and a full admin panel
Multi-RC architecture to support the bot's adoption in multiple RCs
The automatic lifecycle management where groups and resources manage themselves with zero staff involvement once configured

What we learned

grammY's middleware model is surprisingly powerful for building complex Telegram flows cleanly, treating a bot like a web server with layered middleware is the right mental model
Supabase's Row Level Security is genuinely useful for multi-user apps, but requires careful design upfront

What's next for LFGroupBot

Production deployment on Cloudflare Workers — switching from long polling to webhooks and replacing setInterval with Cron Triggers for global edge deployment
Favourite resources — get notified automatically when your favourite pool table or console becomes free
Reputation system — track reliability (did you actually show up?) to encourage accountability in groups