![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 22 22" xmlns="http://www.w3.org/2000/svg"><path d="M 0 0 L 0 19.127 L 8.709 22 L 8.709 5.347 C 8.709 0 0 0 0 0 Z M 5.532 19.142 L 3.177 18.371 L 3.177 2.631 L 3.592 2.759 L 4.224 2.953 C 5 3.192 5.532 3.934 5.532 4.776 Z M 18.741 6.199 L 18.741 0 C 18.741 0 10.031 0 10.031 5.347 L 10.031 22 L 18.74 19.127 L 18.74 8.753 L 14.529 10.058 L 14.529 13.606 L 15.564 13.306 L 15.564 18.371 L 13.208 19.142 L 13.208 4.776 C 13.208 3.934 13.741 3.192 14.517 2.953 L 15.564 2.631 L 15.564 7.251 L 18.74 6.199 Z" fill="rgb(0, 0, 0)" height="22px" id="iRPdBku8W" transform="translate(1.63 0)" width="18.740741374796762px"/></svg>)
Pubby is a mobile platform that lets people discover events and venues in their city. Venues are run by a Manager who publishes events and handles table bookings, while Base Users follow the venues they care about, receive event updates and book a table. An Event Organizer role works like a Manager but without a venue, and an Admin oversees verification and monitoring from a dedicated backoffice.
The design covered the full product end to end: authentication with email, OTP and password recovery, two onboarding tracks for users and venues, a discovery home with search and filters, venue and event detail pages, table booking with automatic confirmation logic, booking states, QR codes, a referral programme with invite codes and vouchers, and push notifications. The Manager side adds a dashboard, time-slot management, event creation built on a shift structure and team management.
One account, two roles
The core design problem was architectural, not cosmetic. The same person can be a Base User and a Manager, and needs to move between the two without friction. I designed Pubby around a single account with switchable profiles rather than two separate apps. The Base User side centres on discovery, following venues, and booking, with a referral programme built on invite codes and vouchers layered on top.
A booking flow built as a state machine, not a form
Table booking couldn't just be a form submission. It needed automatic confirmation logic, defined booking states, and QR codes for check-in, all reliable enough for a Manager to run a real venue on. The Manager side extends the same logic into operations, with a shift-based structure for event creation, time-slot management, and team management, built around how venues actually schedule their day rather than a generic calendar.
