Archived case study · Currently paused
bqueue
bqueue let customers check a barbershop's queue, join from their phone and arrive closer to their turn.
The problem
Customers did not know how long the queue was until they arrived.
bqueue showed the live queue before a customer travelled. They could join from their phone, track their position, see an estimated wait and get an alert when their turn was close.
What I built
The backend and cloud setup.
I built the backend, PostgreSQL data model, live queue updates and notification system. I also led the technical direction of the product.
The system used SSE to send live queue changes. Its multi-tenant setup kept each business's data and requests separate.
Architecture
What happened in the pilot
The product worked, but it did not fit easily into the shops' routines.
Two UK barbershops tested bqueue. The queue workflow worked, but regular use required staff to change how they already ran the shop.
I decided to pause the product instead of forcing a solution that the shops were not ready to use consistently.
What I learned
Good software still has to fit the way people work.
bqueue taught me to think about adoption, staff habits and incentives as part of the product, not as problems outside the software.
If I return to the idea, I would reduce the amount of change required from shop staff and show the value much earlier.
Back to flagship work
RelayX ↗