The Problem
Everyone hates waiting in line. In Finland, you go to a bank, a government office, or a busy store, and you pull a number from a physical machine. The machine itself works fine — you get a number, that part is not the issue. The real problem is what happens after. You have to stay there, physically, staring at the screen on the wall, because that is the only way to know the queue status. There is no way to check remotely. You cannot go grab a coffee, you cannot walk around, you cannot do anything useful — because the moment you leave, you lose track of when your turn is coming.
I notice this everywhere — banks like Nordea, events like Ultrahack, hair salons, tax offices. The queue number system is not broken, but it forces you to be physically present just to get information. That is the actual waste. Not the queue itself, but the fact that you must stay and watch it.
The Solution
ResQue is a remote-based queuing system. The idea is simple: replace the physical machine with a phone. A customer goes to the venue, scans a QR code or registers on their phone, gets a queue number, and then they are free to leave. They can track the queue status in real-time from anywhere. When their turn is close, they get a notification.
For the business side, there is no hardware to buy. Just set up your queue through our dashboard, and customers use their own phones. It is cheaper, more flexible, and gives businesses data about waiting patterns they never had before.
The Hard Design Decision
The most interesting challenge is not technical — it is a product design problem. Early on, we consider letting people take a queue number from home. Sounds convenient, right? But think about this: a tax office opens at 8:00. At 7:59, 100 people at home all grab a number. At 8:00, the queue shows 100 people, but nobody is actually at the venue. The person who walks in and gets number 101 has to wait while the counter skips through 100 absent people.
This is a real problem. After talking to several potential customers — event organizers at Ultrahack, startup community at Kiuas, and some judges from University of Helsinki — we decide to pivot. The rule becomes: you must be at the venue to take a number. But after that, you can leave and track remotely. This way the queue stays honest, and the user still gets the benefit of not standing around.
This is a good lesson. Sometimes the most obvious feature (queue from home) actually breaks the system. You only find this out by talking to real users and thinking through edge cases carefully.
Handling Offline Users
Not everyone has a smartphone. We explore a few options:
- Print integration. Connect a small printer to our system that prints a traditional queue number, so offline users can still join the same queue. The downside is they cannot get notifications.
- Hardware buzzer. Like those pagers you get at Hesburger or Burger King that buzz when your food is ready. Could work for notifications, but hard to show queue status on it.
- Separate lines. The simplest option — businesses can run a separate offline queue alongside the online one.
We do not have a perfect answer yet. But thinking through these scenarios early helps us design the system in a way that does not lock us into only supporting online users.
Architecture
- Frontend: AngularJS for the customer-facing web app
- Mobile: Ionic for cross-platform mobile (iOS + Android)
- Backend: Firebase for real-time data sync, authentication, and hosting
- Real-time updates: Firebase Realtime Database handles the live queue status — when a number is served, every connected client sees the update immediately
Firebase is a good fit here because the core interaction is real-time state synchronization. Every customer watching the same queue needs to see the same number at the same time. Firebase handles that out of the box without us building a WebSocket layer from scratch.
Traction
We follow a lean startup approach — test the problem first, then test the solution:
- Customer discovery. We talk to businesses and event organizers to validate that queuing is actually a pain point worth solving. The answer is yes, especially for larger venues.
- MVP. We build a working prototype and post it on the Kiuas Facebook group. About 40+ people sign up to try it.
- First adopter. Kiuas (a Finnish startup accelerator) becomes our first real user.
- Ultrahack Sprint I 2017. We participate in the hackathon to get more feedback and exposure.
ResQue made it to the Kiuas Team Up finalists:
The team at Kiuas:
What I Am Learning
This project is different from my other side projects because it is not just about building something — it is about figuring out if the thing should exist in the first place. The lean service creation process (customer discovery, solution testing, proceed or pivot) forces you to validate assumptions before writing code. As an engineer, my instinct is to build first and ask questions later. This project is teaching me to flip that around.