Inspiration
I wanted to build something that respects people’s time without changing the restaurant experience. The goal wasn’t “skip queues” in a gimmicky way—it was to make waiting transparent and predictable, and to give restaurants a lightweight tool that improves flow without needing expensive hardware or complicated systems.
What it does
QueueLah started from a simple frustration: in Singapore, queueing is practically a national pastime—whether it’s lunch crowds in the CBD, weekend brunch lines, or dinner peak hours in neighborhoods like Tiong Bahru and Bugis. I kept noticing the same pain points on both sides: diners waste time hovering near a restaurant with no certainty, and restaurants spend valuable staff attention managing a line, answering “how long more?” questions, and dealing with no-shows.
How we built it
We built QueueLah as a full-stack, real-time web app: Frontend: React (Vite) + React Router for routing and a clean, responsive UI Backend: Firebase (Firestore + Authentication) to keep the app real-time and simple to deploy Core concept: the queue is a live dataset; the UI is always “subscribed” to changes so diners and staff see updates instantly The diner experience focuses on:
- browsing restaurants
- joining a queue remotely
- tracking queue position live
- clear status messages when you’re close to the front The restaurant side focuses on:
- a staff dashboard that shows the “Front of Queue” (only the next few parties)
- an Estimated Queue Time that scales based on queue size
- tools to manage flow (seat parties, start timers, pause the queue)
- a Missed Queue list for parties who miss their return window (so the main queue stays fair and moving)
Challenges we ran into
“Blank page” bugs caused by config mismatch: A missing or mismatched Firebase environment setup can fail at runtime even when the build succeeds. The fix was tightening the env setup and ensuring the correct Firebase project was used consistently. Firestore indexing constraints: Real-time queries that filter + sort often need composite indexes. Building the right index fixed errors that looked like logic bugs at first. Authorization for restaurant dashboards: I implemented an ownership-based approach so only the correct restaurant account can access dashboard/:restaurantId, preventing accidental or malicious access. Queue fairness edge cases: Handling “missed turns” cleanly is surprisingly important—if someone doesn’t return, they shouldn’t block the queue. That led to the “Missed Queue” concept and the skipped status flow. UI/UX details that matter more than expected: Small issues like spacing, alignment, and dropdown layering can break the “polished” feel. I iterated on layout and interactions to keep it clean and intuitive.
Accomplishments that we're proud of
QueueLah became a focused, real-time queue management system: diners get clarity and freedom, restaurants get control and smoother operations, and the queue stays fair even during peak periods. It’s a practical project built from a local problem, and it taught me how to bridge product thinking with technical execution.
What we learned
This project taught me that “real-time” isn’t just a technical feature—it’s a product decision. When everything updates instantly, you have to be careful with:
what counts as “waiting” vs “called” vs “skipped” how you calculate estimates so they match user expectations (for example, queue time should be 0 when no one is waiting) making dashboards reduce decision fatigue rather than adding more numbers I also learned a lot about Firebase design:
structuring Firestore queries to support real-time subscriptions handling composite indexes when queries get more advanced designing auth and ownership rules so restaurant dashboards are protected correctly
What's next for QueueLah
neater designs, faster loading times
Built With
- firebase
- tailwind
- typescript
Log in or sign up for Devpost to join the conversation.