Inspiration

Waiting in queues is one of those everyday problems that feels unavoidable. Whether it is a restaurant, salon, clinic or other busy place people often have to stay just because they don't know when their turn will come.

We wanted to change that experience: what if joining a queue didn't mean standing in it?

That idea became Waitee, the customer-facing app of Queuwu. Of spending time standing around users can join a queue remotely leave the location track their position and return when their turn is approaching.

What it does

Waitee lets users:

  • Discover businesses and their queues.

  • Join a queue remotely.

  • Leave the location while waiting.

  • See their position and the current queue status in time.

  • Receive notifications as their turn gets closer.

  • View their queue visits.

  • Use Queue+ for Smart Return Timing, which uses the pace of the current queue to provide a more useful return estimate.

The system also includes a Host application for businesses to manage their queues.

How we built it

We built Queuwu as a full-stack system with:

  • Flutter/Dart for the Waitee and Host mobile applications.

  • FastAPI/Python for the backend.

  • PostgreSQL for queue and business data.

  • . Alembic for database access and migrations.

  • WebSockets for real-time queue updates.

  • RevenueCat for Queue+ subscriptions and entitlement management.

  • Flutter Local Notifications for queue milestone notifications.

A major focus was keeping the queue state consistent. Of repeatedly polling the backend Waitee maintains a WebSocket connection to the active queue. When the queue changes the backend broadcasts the updated state and the app updates automatically.

For Queue+ we deliberately avoided pretending that we had an AI prediction model when we didn't have historical data. Instead Smart Return Timing measures the actual pace of the current queue session* and uses that live signal to improve the estimate.

Challenges we ran into

One of the challenges was making the queue experience genuinely real-time while keeping the app state consistent across different screens.

We also had to handle cases such as:

  • Reconnecting to a WebSocket.

  • Restoring a queue after reopening the app.

  • Preventing queue state.

  • Keeping queue history associated with the user.

  • Triggering notifications when a user actually crosses a queue milestone.

  • Removing demo/ data without breaking the real application flow.

  • Designing Queue+ without fabricating data or making AI" claims.

  • Integrating RevenueCat while keeping the free queue experience usable.

We also spent effort making the backend safer by moving away from a client-controlled user ID toward signed authenticated sessions.

Accomplishments that we're proud of

We are proud that Queuwu became more than a UI prototype.

The core customer journey works as a system:


Discover a queue

↓

Join remotely

↓

Leave the physical location

↓

Track the queue in real time

↓

Get notified as your turn approaches

↓

Return when needed

↓

Keep the visit in your history

We also built Queue+ as an actual RevenueCat-powered premium feature rather than a static premium screen.

Another thing we're proud of is our approach to data integrity. When we didn't have historical data to make a meaningful prediction we didn't invent one. Smart Return Timing only becomes "smart" when the current queue has provided real movement data.

What we learned

We learned that building a simple product like a queueing app involves much more than creating screens.

We learned about:

  • Real-time application architecture with WebSockets.

  • Persistent client-side state.

  • Designing APIs around user flows.

  • Authentication and user isolation.

  • Database. Backend testing.

  • Local notification systems.

  • Subscription and entitlement management with RevenueCat.

  • Handling loading, error and empty states.

  • Designing a premium feature around data that actually exists.

  • The difference between a working prototype and a production-oriented application.

Importantly we learned to build around real signals instead of assumptions. If the data isn't there the product shouldn't pretend that it is.

Whats next for Queuwu

We want to take Queuwu beyond the hackathon prototype and make it useful, for real-world businesses.

Our next steps include improving the business/Host experience strengthening production deployment and monitoring expanding authentication and account management and collecting real queue data to make future wait-time predictions increasingly accurate.

The long-term goal is simple:

Queues should tell people when they need to be instead of forcing people to wait there.

Android App — Closed Testing

The Android app is available on Google Play through closed testing.

How to join the test:

  1. Join the Google Group: https://groups.google.com/g/queuwu-testers
  2. Press “Join group” at the top of the page.
  3. Open the Google Play testing link: https://play.google.com/apps/testing/com.queuwu.app and https://play.google.com/apps/testing/com.queuwu.host
  4. Opt in to the test and install the app from Google Play.

Note: You must join the Google Group before accessing the closed test.

Built With

Share this project:

Updates

posted an update —

The app is available on the Google Play Store through closed testing.

To access it:

  1. Join the Google Group here: https://groups.google.com/g/queuwu-testers
  2. Press “Join group” at the top of the page.
  3. Once you've joined the group, open the Google Play testing link provided in this project and opt in to the test.

Please make sure you join the Google Group first, as membership is required to be eligible for the closed test. Thank you!

Log in or sign up for Devpost to join the conversation.

Submission history